Understanding Identifier Alignment

DMARC requires that a message not only pass DKIM or SPF validation, but that its identifier domains are "in alignment." Identifier alignment forces the domains authenticated by SPF (typically the MailFrom domain but can be the HELO domain if the MailFrom was empty) and DKIM (the DKIM signing domain as shown in the DKIM-Signature header's d= field) to have a relationship to the “header From” domain, which is more typically visible to a user in email clients. In “strict” alignment mode the domains must be an exact match. In “relaxed” alignment mode the domains can be different sub-domains of the same organizational domain.

For SPF, the message must pass the SPF check and the domain in the From: header must match the domain used to validate SPF (must exactly match for strict alignment, or may be a sub-domain for relaxed alignment, which is the default). See also SPF Alignment.

For DKIM, the message must pass the DKIM check and the d= domain of the valid signature must align with the domain in the From: header (must exactly match for strict alignment, or must be a sub-domain for relaxed alignment).

TIP: Even if SPF and DKIM pass authentication, DMARC will still fail if the identifiers are not aligned.

These are the terms used in identifier alignment:

• Header From domain: This is the domain portion of the email address that is most commonly visible to end users in the “From:” field displayed in an email client. It is not the display name, which is also commonly displayed in the same “From:” field. For example, the following may be displayed in an email client “From: Agari <donotreply@blah.agari.com>”. In this example “Agari” is the display name, while “agari.com” is the organization domain although "blah.agari.com" is the actual domain of the From header.
• SPF domain: This identifier is used by the SPF authentication mechanism. Most commonly this is the domain used in the SMTP conversation's mail-from. However if the mail-from is empty (as with bounces, OOO notifications, and some other scenarios), then receivers will usually check for SPF passes with the host given in the HELO/EHLO of the message submission.
• DKIM domain: This identifier is used by the DKIM authentication mechanism. It is the domain designated by the ‘d=’ tag in the DKIM-Signature header.
• DKIM public key: used to decode the DKIM signature in a message is discovered from a DNS lookup that combines this ‘d=’ domain with the DKIM selector (‘s=’), also found in the DKIM-Signature header. The public key is specifically found in DNS at the TXT location of: {s}._domainkey.{d}, where s and d are found in the DKIM-Signature header of an email message.