Question incoming mail DMARC failure - need expert eyes

[TomBoB]

Server operating system version

AlmaLinux 8.7

Plesk version and microupdate number

Plesk 18.0.50 #2

I need a specialists extra pair of eyes on this one please. For my understanding. Plesk related as we use PES, and I'm not 100% certain that the issue is caused by the senders DMARC settings, or possibly by something PES does/injects.

In short, itinerary mail comes in to client from amadeus ticketing system. Mail is rejected due to DMARC. Here is what puzzles me:
The last entry shows

DMARC: smtpdomain=amadeus.com maildomain=flightticketseller.com mailfrom=[email protected]

I read that as: amadeus.com sends the mail from their mail server, but claims it comes from the sellers domain, using the sellers email address. This triggers the DMARC reject as flightticketseller.com isn't allowed to send via amadeaus.com .
To me this points at a mistake at amadeus. They shouldn't claim " maildomain=flightticketseller.com mailfrom=[email protected] " in their sent mails.

But am wondering: Amadeus is a big company, and they really shouldn't get this wrong. Do they possibly send the mail with correct headers, and PES interferes by rewriting headers, and adds this " maildomain=flightticketseller.com mailfrom=[email protected] " itself? Which then causes the issue?

Below the full incoming mail log for reference.

[Should be asking this at stackexchange or similar, but as PES is used on our servers, want to rule out its interference first]

2023-02-28 10:34:46	warning	dmarc [253101]	8362BC737F: DMARC: smtpdomain=amadeus.com maildomain=flightticketseller.com mailfrom=[email protected] stamp=1677573286 ip=127.0.0.1 adkim=relaxed aspf=relaxed p=REJECT sp=UNSPECIFIED pct=100 align_dkim=fail align_spf=fail spfres=pass dkimres=unknown dmarccheck=DMARC_POLICY_REJECT dmarcstatus=STOP
2023-02-28 10:34:45	info	postfix-local [253099]	8362BC737F: from=<[email protected]>, to=<[email protected]>, dirname=/var/qmail/mailnames
2023-02-28 10:34:45	notice	amavis [237718]	(237718-09) Passed CLEAN {RelayedInbound}, [82.150.225.79]:35673 [82.150.225.79] <[email protected]> -> <[email protected]>, Queue-ID: 16693C61D3, Message-ID: <PAP/NMC-SAFRIC/C55E153F3917/[email protected]>, mail_id: dUuhUzqQzI6Z, Hits: -2.288, size: 329802, queued_as: 8362BC737F, 4345 ms
2023-02-28 10:34:45	info	postfix/qmgr [1744]	8362BC737F: from=<[email protected]>, size=330596, nrcpt=1 (queue active)
2023-02-28 10:34:45	info	postfix/cleanup [251361]	8362BC737F: message-id=<PAP/NMC-SAFRIC/C55E153F3917/[email protected]>
2023-02-28 10:34:45	info	psa-pc-remote [813]	8362BC737F: from=<[email protected]> to=<[email protected]>
2023-02-28 10:34:45	info	postfix/smtpd [240914]	8362BC737F: client=server.hostingclientdomain.com[127.0.0.1], orig_queue_id=16693C61D3, orig_client=relay.amadeus.net[82.150.225.79]
2023-02-28 10:34:41	info	postfix/smtpd [251248]	disconnect from relay.amadeus.net[82.150.225.79] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
2023-02-28 10:34:41	info	postfix/qmgr [1744]	16693C61D3: from=<[email protected]>, size=329511, nrcpt=1 (queue active)
2023-02-28 10:34:41	info	postfix/cleanup [251084]	16693C61D3: message-id=<PAP/NMC-SAFRIC/C55E153F3917/[email protected]>
2023-02-28 10:34:41	info	psa-pc-remote [813]	16693C61D3: from=<[email protected]> to=<[email protected]>
2023-02-28 10:34:41	info	postfix/smtpd [251248]	16693C61D3: client=relay.amadeus.net[82.150.225.79]
2023-02-28 10:34:40	info	postfix/smtpd [251248]	connect from relay.amadeus.net[82.150.225.79]

 

[TomBoB]

Sorry, haven't got a server without PES , or one where i can remove it, available for testing currently...

 

[scsa20]

I think the main problem is the mail from address since there would still need to be records indicating that amadeus.com would be allowed to use the flightticketseller.com domain. Problem is, flightticketseller.com doesn't seem to exist.

I would suggest that you reach out to whoever is managing the email server from the other end to make sure their email settings are sent properly since flightticketseller.com doesn't exist.

 

[TomBoB]

Can't publish the real mail addresses. The ones for clientdomain.com and flightticketseller.com are placeholders. Only the amadeus addresses are real.

Principally, you confirm what I'm suspecting. The issue really lies with amadeus. Who claims to be sending from the ticket sellers address, when their own dmarc record prohibits such.

 

[mow]

Does amadeus set a Sender: header? SPF/DMARC can work with that too - that's also the workaround for forwarded mails.

 

[TomBoB]

No, apparently not. We've opened a ticket with them to get to know exactly how it is working their side.