SPF Record Mechanisms | SPF Record Qualifiers | DMARC Record Options | DKIM Checker

Easydmarc Toolbox - A good toolbox for overall email health and our Recommended DMARC Reporting Site

SPF record mechanisms

Use the mechanisms in this table to create your SPF record. Receiving mail servers check messages against mechanisms in the order they are listed in the SPF record.

Tip:

You can use optional SPF record qualifiers with mechanisms.
Your TXT record for SPF shouldn’t include more than 10 references to other domains or servers. These references are called lookups.

Mechanism	Description and allowed values
`v`	SPF version. This tag is required, and must be the first tag in the record. This mechanism must be: `v=spf1`
`ip4`	Authorize mail servers by IPv4 address or address range. The value must be an IPv4 address or range in standard format, for example: `ip4:192.168.0.1` or `ip4:192.0.2.0/24`
`ip6`	Authorize mail servers by IPv6 address or address range. The value must be an IPv6 address or range in standard format, for example: `ip6:3FFE:0000:0000:0001:0200:F8FF:FE75:50DF` or `ip6:2001:db8:1234::/48`
`a`	Authorize mail servers by domain name, for example: `a:clusterednetworks.com`
`mx`	Authorize one or more mail servers by domain MX record, for example: `mx:mail.clusterednetworks.com` If this mechanism isn't in your SPF record, the default value is the MX records of the domain where the SPF record is used.
`include`	Authorize third-party email senders by domain, for example: `include:servers.mail.net`
`all`	Specifies that all incoming messages match. We recommend you always include this mechanism in your SPF record. This must be the last mechanism in the SPF record. Any mechanism that comes after the `all` mechanism in an SPF record is ignored. Should I use ~all or -all? When an SPF record includes `~all` (softfail qualifier), receiving servers typically accept messages from senders that aren't in your SPF record, but mark them as suspicious. When an SPF record includes `-all` (fail qualifier), receiving servers may reject messages from senders that aren't in your SPF record. If your SPF record isn’t set up correctly, the fail qualifier might cause more messages from your domain to be sent to spam. Tip: To prevent spoofing of domains that don’t send email, use this as the SPF record for the domain: `vspf1 ~all`

A complete example of an SPF record is listed below.

v=spf1 mx ip4:209.85.220.69 ip4:35.195.220.65 ip4:68.148.157.91 ip4:104.131.221.179 ip4:18.223.170.225 include:_spf.google.com include:spf.mailjet.com ~all

SPF record qualifiers

A qualifier is an optional prefix you can add to any mechanism in your SPF record. Qualifiers tell the receiving mail server whether to consider a message authenticated when there's a match with a mechanism value, for example:

v=spf1 include:_spf.google.com ~all

In this example, the SPF record authorizes only Google Workspace to send emails for your domain. The all mechanism has a soft-fail qualifier ( ~ ), so messages from any other senders fail the SPF check and may be rejected by the receiving server.

Mechanisms are checked in the order they occur in the SPF record. If a mechanism doesn’t have a qualifier and there’s a match, the default action is pass authentication. When there's no mechanism match, the action default is neutral: the message doesn't pass or fail authentication.

Use these optional qualifiers to tell receiving mail servers how to handle messages that match mechanisms in the SPF record.

Qualifier	Action receiving server takes with a match
`+`	Passes authentication. The server with matching IP address is authorized to send for your domain. Messages are authenticated. This is the default action when the mechanism doesn’t use a qualifier.
`-`	Fails authentication. The server with matching IP address is not authorized to send for the domain. The SPF record doesn’t include the sending server IP address or domain so messages won’t pass authentication.
`~`	Softfails authentication. It's unlikely that the server with matching IP address is authorized to send for the domain. The receiving server will typically accept the message but mark it as suspicious.
`?`	Neutral. Neither passes nor fails authentication. The SPF record doesn’t explicitly state that the IP address is authorized to send for the domain. SPF records with neutral results often use `?all`

A complete example of an SPF record is listed below with a [ -all ] qualifier.

v=spf1 mx ip4:209.85.220.69 ip4:35.195.220.65 ip4:68.148.157.91 ip4:104.131.221.179 ip4:18.223.170.225 include:_spf.google.com include:spf.mailjet.com ~all

A good Description of how SPF Alignment works can be found at this link. https://mxtoolbox.com/dmarc/spf/spf-alignment

Websites you can use to check SPF Records

Dmarcly - https://dmarcly.com
Demarcian.com - https://dmarcian.com/spf-survey/
MXToolbox.com - MXToolBox.com

DMARC Record Options Chart

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Tag	Default	Translation
v	DMARC1	The DMARC version should always be “DMARC1”. Note: A wrong, or absent DMARC version tag would cause the entire record to be ignored.
p	none	Policy applied to emails that fails the DMARC check. Authorized values: “none”, “quarantine”, or “reject”. “none” is used to collect feedback and gain visibility into email streams without impacting existing flows. “quarantine” allows Mail Receivers to treat email that fails the DMARC check as suspicious. Most of the time, they will end up in your SPAM folder. “reject” outright rejects all emails that fail the DMARC check.
adkim	r	Specifies “Alignment Mode” for DKIM signatures. Authorized values: “r”, “s”. “r”, or “Relaxed Mode”, allows Authenticated DKIM d= domains that share a common Organizational Domain with an email’s “header-From:” domain to pass the DMARC check. “s”, or “Strict Mode” requires exact matching between the DKIM d= domain and an email’s “header-From:” domain.
aspf	r	Specifies “Alignment Mode” for SPF. Authorized values: “r”, “s”. “r”, or “Relaxed Mode” allows SPF Authenticated domains that share a common Organizational Domain with an email’s “header-From:” domain to pass the DMARC check. “s”, or “Strict Mode” requires exact matching between the SPF domain and an email’s “header-From:” domain.
sp	p= value	Policy to apply to email from a sub-domain of this DMARC record that fails the DMARC check. Authorized values: “none”, “quarantine”, or “reject”. This tag allows domain owners to explicitly publish a “wildcard” sub-domain policy.
fo	0	Forensic reporting options. Authorized values: “0”, “1”, “d”, or “s”. “0” generates reports if all underlying authentication mechanisms fail to produce a DMARC pass result, “1” generates reports if any mechanisms fail, “d” generates reports if DKIM signature failed to verify, “s” generates reports if SPF failed.
ruf	none	The list of URIs for receivers to send Forensic reports to. Note: This is not a list of email addresses, as DMARC requires a list of URIs of the form “mailto:[email protected]”.
rua	none	The list of URIs for receivers to send XML feedback to. Note: This is not a list of email addresses, as DMARC requires a list of URIs of the form “mailto:[email protected]”.
rf	afrf	The reporting format for individual Forensic reports. Authorized values: “afrf”, “iodef”.
pct	100	The percentage tag tells receivers to only apply policy against email that fails the DMARC check x amount of the time. For example, “pct=25” tells receivers to apply the “p=” policy 25% of the time against email that fails the DMARC check. Note: The policy must be “quarantine” or “reject” for the percentage tag to be applied.
ri	86400	The reporting interval for how often you’d like to receive aggregate XML reports. You’ll most likely receive reports once a day regardless of this setting.

A complete example of an DMARC record is listed below.

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; aspf=r;

There are 2 different types of DMARC reports, aggregate reports, and the forensic reports. These reports are sent by email receivers to email senders for them to analyze various aspects of their outbound emails. You should be able to view the reports from your DMARC Report hosting provider or where you get them sent to.

Aggregate reports are received every 24 hours and include the origination details of your emails, which include the source IP address your email was generated from along with the result of your SPF and DKIM authentication. These 2 mechanisms are used by email senders to authorize their email sources. The information from aggregate reports is used to identify all your legitimate email sources and authorize them accordingly.

Forensic reports are received every time an email from your domain fails both the authentication mechanisms, SPF & DKIM. This is used for in depth analysis on emails spoofing your domain, since these reports contain details of the spoofed email, e.g. from an email address to an email address, the subject, and in some cases, the header of the email. It is recommended to enable these reports after analysis of aggregate reports and authorizing all your legitimate sources to reduce noise, and only receive forensic reports of spoofed emails.

In summary, aggregate reports help you identify and authorize your legitimate emails while forensic reports aid in analyzing spoofed emails and identifying attack attributes to take down. Through these reports, the DMARC framework plays a significant role in eliminating various email impersonation fraud!

DKIM Record Checker

DKIM Record Checker - Checking your DKIM is very important in making your email flow properly. Use these links to check your DMIM to make sure it is valid.