In the early days of the internet, it was possible for anyone to send email in the name of anyone, just the way you can still today send a postal letter from any sender address by just writing any sender address onto the envelope.
As this is not very secure and spam emails became a huge problem, in recent times efforts were taken to verify the sender of an email. DMARC and its two sub-standards SPF and DKIM were born.
DMARC makes sure that if a sender tries to impersonate a specific email address (called spoofing), the receiving mail server has ways to find out about it and retain and quarantine the spoofed message or mark it as spam and deliver it as such to the recipient’s inbox.
Websites (and web applications) sometimes need to send email on behalf of an organization’s email address. The typical case is a contact form on the website that is sent from info@acme.org to info@acme.org and to the email of the user that submitted the form.
In such cases it’s a best practise to use a Email Gateway Provider such as Sparkpost to handle the emailing. However, won’t all email sent through such convenient services be retained or go to Spam, because of DMARC?
System administrators can configure Email Gateway Providers by setting up DKIM and SPF records in the sending domain’s DNS settings. Like this, receiving email servers know which senders are authorized to send email for a specific sending domain.
There is one limitation though it has no effect on the validity of emails sent: Spam filters and DMARC monitoring and analysis tools will show a warning that DMARC SPF is not valid. However DMARC specifies that email is valid if either DKIM or SPF checks out. Since DKIM checks out (if properly configured) even for email sent through Email Gateway Providers, this warning can be ignored by system administrators. For system administrators it is important that they configure their systems to allow email from sources where either DKIM OR SPF alignment checks out, as emails from your website might otherwise go to user’s spam. Optionally, some Email Gateway providers offer to configure a custom return-path domain which would remove the warnings completely.