SPF asserts that a given IP address is authorized to send mail from a particular envelope sender domain (the user typically does not see this domain) An email with a user visible From address of [email protected] can have passing SPF from evil.com

DKIM asserts that the message contents have been sent by a particular domain (or domains), that domain does not necessarily relate to either the envelope sender domain, or the domain the user sees in the From address. Again, an email from [email protected] can have a perfectly valid DKIM signature from phisher.com

DMARC is a policy layer over the top of these, which ties the domain the user actually sees in the From address back to those used in SPF and DKIM. This is where the [email protected] email starts getting blocked. Neither the SPF nor DKIM of the email are "aligned with" whitehouse.gov, and we can start to do something about the spoofing.

Thanks for the explanation marcbradshaw / volundr . It really cleared things up for me.

It's simplest terms, SPF allows you to prove (and equally importantly disprove) that a piece of mail comes from your domain based on IP address (there are a variety of mechanisms, but in the end it all boils down to IP). Basically SPF spells out specifically which hosts are allowed to send mail from your domain.

DKIM allows you to prove a message originates from your domain via a cryptographic signature. So any mailserver with the private key can send messages from your domain, it's not limited to a predetermined subset.

In different situations one can be more useful than the other. It's also recommended to implement both, as one or the other might fail for various reasons.

It's also worth noting you really should implement DMARC as well, which lets you spell out a policy for what recipients should do if SPF and DMARC fail, including if they should notify you and how.

Just please set up DMARC so it allows forwarding a mail... Have had this problem a number of times lately, companies sending mail to us that just vanish in thin air without any explanation. Turns out an alias adress is forwarding their mail to whoever is supposed to handle their mail at the moment and this is not allowed due to how they set up DMARC. The mail server just drops the mail without warning.

If forwarding is failing DMARC, that's on your system, not the senders. There is nothing the sender can do to help the situation.

Basically DMARC needs either DKIM OR SPF to pass to consider a message passing. Being no SPF record will ever include (forwarders aren't allowed to originate messages from the domain) that means DKIM has to pass.

DKIM works by signing the message body and selected headers with a private key, while the public key is published to DNS. This allows a receiver to fetch the public key from DNS and validate it was really sent by the sender. It should be clear at this point that you'll be able to forward a DKIM signed message as much as you want as long as you don't modify the message when sending. If on the other hand your forwarder modifies the headers (including subject) or the body DKIM will fail.

In other words, if your going to use a forwarder, make sure that forwarder will forward the message as is. You can add headers, but don't remove or modify any existing headers and don't modify the message itself.

O2's billing emails, and a well known bank have broken DKIM signatures as they are improperly forwarded.

No chance of getting through to their tech support, especially since these types of email are usually from a no-reply@ address and the people manning the phones are not the mail server admins anyway.

try emailing postmaster@

No joy there either, sadly.