• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Question incoming mail DMARC failure - need expert eyes

TomBoB

Silver Pleskian
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:46warningdmarc [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:45infopostfix-local [253099]8362BC737F: from=<[email protected]>, to=<[email protected]>, dirname=/var/qmail/mailnames
2023-02-28 10:34:45noticeamavis [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:45infopostfix/qmgr [1744]8362BC737F: from=<[email protected]>, size=330596, nrcpt=1 (queue active)
2023-02-28 10:34:45infopostfix/cleanup [251361]8362BC737F: message-id=<PAP/NMC-SAFRIC/C55E153F3917/[email protected]>
2023-02-28 10:34:45infopsa-pc-remote [813]8362BC737F: from=<[email protected]> to=<[email protected]>
2023-02-28 10:34:45infopostfix/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:41infopostfix/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:41infopostfix/qmgr [1744]16693C61D3: from=<[email protected]>, size=329511, nrcpt=1 (queue active)
2023-02-28 10:34:41infopostfix/cleanup [251084]16693C61D3: message-id=<PAP/NMC-SAFRIC/C55E153F3917/[email protected]>
2023-02-28 10:34:41infopsa-pc-remote [813]16693C61D3: from=<[email protected]> to=<[email protected]>
2023-02-28 10:34:41infopostfix/smtpd [251248]16693C61D3: client=relay.amadeus.net[82.150.225.79]
2023-02-28 10:34:40infopostfix/smtpd [251248]connect from relay.amadeus.net[82.150.225.79]
 
Sorry, haven't got a server without PES , or one where i can remove it, available for testing currently...
 
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.
 
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.
 
Does amadeus set a Sender: header? SPF/DMARC can work with that too - that's also the workaround for forwarded mails.
 
No, apparently not. We've opened a ticket with them to get to know exactly how it is working their side.
 
Back
Top