SPF Alignment
Having a thorough understanding of alignment is important for any DMARC project, regardless of email volume, program complexity or third-party source sending email on your behalf. The good news is that there isn’t much to learn.
While DMARC provides domain owners with both visibility and overarching control over how their domain is being used, alignment is achieved on a much more granular level.
Alignment helps prove that the domain owner has taken responsibility for the message and authorized the email source to send on their behalf. This is accomplished by publishing explicit entries into DNS for that domain, as specified by the email source (sender/vendor) doing the actual sending. When considering that access to DNS is heavily guarded, these are tasks that can only be carried out by the true domain owner or assigned administrator. As such, keep the following in mind:
- Emails that are aligned and pass authentication are DMARC compliant and pass DMARC.
- Emails that fail alignment do not pass DMARC.
For an email to align, the domain seen by humans in the From header (e.g., hello@dmarcian.com) must match either of the domains used to pass SPF or DKIM.
In this illustrative Table/Example, all DKIM and SPF checks pass:
Specifically for SPF alignment, the domain used in the From address must match the domain used to pass SPF.
- It’s important to know that SPF checks are done against the domain found in the Return-Path, NOT the domain found in the From address.
- The industry never came to an agreement on what to call this value, so you may have heard it referred to as either the bounce domain, envelope-domain, MailFrom domain or RFC 5321 domain.
- The Return-Path is an element in the message transmission itself, unlike the subject line, cc/bcc recipients, etc.
- There are more nuances to this, such as if the SMTP's message transmission MailFrom is blank, then the value specified in the conversation's HELO is used to check SPF instead - this is when you see what appears to be a machine name in the value checked for SPF. For more nitty gritty on SPF please continue reading our articles or the actual specification.
- Simply adding IP addresses or include statements to your SPF record is usually not sufficient. You likely need to complete a configuration step with the email source sending on your behalf to change their default value in order to begin using your domain. At the onboarding stage with your email source, they likely made this configuration optional, although more and more, sources are making it a requirement, especially after Yahoo and Google increased stringency around email standards and best practices enforcement in early 2024. Before that, many email sources/senders didn’t want to bother domain owners with this additional configuration because it was perceived as a roadblock for less technical users.
- Where supported, we recommend the use of a subdomain. Subdomains help isolate the reputation of that particular mail stream and help you avoid hitting some of the inherent limitations associated with SPF (e.g., 10 lookup max, bounce processing, etc.)
- Each email source will have some variation on the instructions they provide. Some will provide individual IP addresses to add to your DNS, whereas others will provide an include statement. Both of these options work just fine.
- Whereas the dmarcian application provides some general guidance on how to configure SPF for each email source (see Source Capabilities), you should follow the instructions provided by the vendor.
Though SPF and DKIM are more common technologies than DMARC, hopefully after reading this guide you’ll understand that neither SPF or DKIM, on their own, have anything to do with the visible From address. This misinterpretation is why phishing, spoofing, Shadow IT and other forms of domain abuse run rampant today.
There are very few controls that prohibit bad actors from sending an email as you. The primary control to observe and restrict domain usage is DMARC.