5 min read

SPF, DKIM and DMARC settings

This is a recap from this article skipping over the intro and other explanation parts. This is a collection of what certain settings mean for seasoned mail server administrators.  


List of allowed domains and IPs for a specific domain.

Example TXT record for example.com:

"v=spf1 include:amazonses.com ~all"
  • v=spf1 refers to the version of SPF that you are using. Right now, SPF1 is the current version
  • Everything that follows the SPF1 refers to a bunch of qualifiers, modifiers, and mechanisms that determine whether the host is allowed to send emails
  • The ip4 refers to an IPv4 address that is allowed to send emails from that domain. In this example, the IP address of 190.168.01 is a qualified domain that can send emails
  • The -all mechanism refers to the domain’s settings. In this case, if none of the mechanisms listed before this matches the SPF record, then the check will fail.

  • P4: this indicates that the SPF record will match if the sender is in an IPv4 range
  • IP6: the SPF record will match if the domain user is sending from an IPv6 range
  • A: domain addresses that have an A or AAAA can be matched to the sender’s address
  • MX: domain addresses that have an MX record will be a match (for example, if the email comes from one of the domain’s incoming servers)
  • PTR: if the domain’s PTR record for your address is in the given domain and this domain defaults to your address, then it will be a match. It should be noted that this mechanism should no longer be used as it is depreciated.
  • EXISTS: this mechanism is rarely used because it contains complex matches. It refers to domain names that match any address, no matter the address.
  • INCLUDE: this refers to another domain’s policy. If the other policy domain passes the check, then this mechanism passes. However, if the policy fails, then processing will continue. The redirect extension must be used to completely delegate another domain’s policy.
  • ALL: this refers to always a match and is used for default, such as -all for all IPs that are not matched by other mechanisms.

SPF Qualifiers

  • + means that SPF checks pass; it can be omitted;
  • ? is a neutral result that can be defined as NONE or no policy;
  • ~ (tilde) refers to soft fail, which is an aid that falls between neutral and fail. Messages that are tagged with a soft fail are accepted but flagged;
  • – refers to fail; in other words, the SPF check fails.

SPF Modifiers

  1. Exp=any.example.com – this gives us the domain of the domain along with a DNS TXT record and provides an explanation for failed checks. This type of modifier is rarely used;
  2. Redirect-any.example.com – this modifier is used instead of the ‘all’ mechanism. It links to the policy of another domain.

DNS Lookup limit

The SPF records process assumes that the number of modifiers and mechanisms that perform DNS lookups do not exceed ten times per check. This includes any lookups that use the ‘include’ mechanism or ‘redirect’ modifier.

PermError will be returned if this number is exceeded during one check. However, the “a,” “mx,” “ptr,” and “exists” mechanisms, as well as the redirect modifier, will not count against this number. Also, the “ip4,” “ip6,” and “all,” mechanisms do not require a DNS lookup. Therefore, they will not count toward the number of SPF lookups. Lastly, the “exp” modifier does not count because the lookup occurs after the SPF record has been evaluated.


Authenticating every email with asymmetric key cryptography (signatures from combination of the content and specific headers).

DKIM TXT example from domain._domainkey.example.com:

v=DKIM1; t=s; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4uH1h5ZM7pTCQq+yBp4MftenTeaw9boAydtC3HyiLHq/c7HCYew5UdJuiPw+kF/T5V8DjW3hngGq1FNmIIKOzNauIpKfRTmr7b6FOXPT9W+iSKmF6W0CXxLtOvu+iXguil96dz6U7mFd+1PFLL3/dD+GkOr4cWBYjZFEzPMs4zQIDAQAB;
  • v: this refers to the DKIM protocol version, which is “DKIM1” by default
  • g: some companies will assign a business function to a certain group, either internally or externally. The ‘g’ tag is used to assign the group to email, and also restrict what signatures they can create. The DKIM g tag helps assist this process
  • h: this tag provides a list of mechanisms that can be used to create a portion of the message data
  • n: this section contains notes for domain users
  • s: this tag provides a list of service types that the sector may apply to
  • q: this section provides a list of query methods, such as ‘dns’
  • l: the l= tag refers to body length limits, which are subject to cyber attacks
  • k: this tag provides a list of mechanisms that are needed to decode a DKIM signature, such as rsa
  • t: this tag provides a list of flags that can be used to modify the interpretation of the selector (optional)
  • p: this refers to an encoded public key (Base64).

The tag=value lists can be found in the DKIM signature header field of an email message. Here is an example of what a DKIM signature header field looks like:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;

The following is a list of tags that can show up in a DKIM-signature header field:

  • x: expire time
  • v: version
  • a: signing algorithm
  • d: domain
  • c: canonicalization algorithm for header and body
  • q: default query method
  • s: selector
  • t: signature timestamp
  • h: header fields – list of those that have been signed
  • bh: body hash
  • b: signature of headers and body


Example TXT record for _dmarc.example.com:

  • noneL Do nothing, which is also called monitoring mode (this is when the email is sent to the inbox despite not passing)
  • quarantine, which is when the email is sent to the spam folder
  • reject, which is when the email is not delivered to the inbox or spam (the recipient will never see it)

  • v=: this tag refers to a DMARC protocol version – “DMARC1” is default
  • p=: this tag refers to policies that can be applied when an email fails a DMARC check. For example, you can set the p= tag to none, quarantine, or reject.
  • rua: this tag refers to a list of URLs that email addresses can send reports to. It should be noted that this is NOT a list of email addresses. DMARC requires rua to provide a list of URLs in the form of “sendto:email@test.com.”
  • ruf: this tag refers to a list of URLs that forensic reports are sent to from ISPs. Just like with rua – this is not a list of email addresses. The format must be sent in the form of the URLs in the rua tag.
  • sp: this tag refers to a policy that can be applied to a domain from a subdomain if an email fails the DMARC check. It allows the domain users to set a type of wildcard for subdomains.
  • fo: this tag stands for “forensic options.” You can use 0 to create reports as long as DKIM and SPF both fail. You can use 1 to create reports if either DKIM or SPF fails to create a DMARC pass – “d” can be used to create a report if DKIM fails or you can use “s” if SPF fails. These options will tell a DMARC check to pass.
  • rf: this tag refers to forensic report formatting
  • pct: this tag tells the ISPs to only use DMARC policies to a certain percentage of failing emails. For example, “pct=70” will direct receiving emails to only apply the p=policy tag 70% of the time for emails that fail the DMARC check. This tag does not work for the ‘none’ p=tag. It only works for policies set to ‘reject’ or ‘quarantine’ failed emails.
  • adkim: this tag tells DKIM signatures that they must be in ‘alignment mode.’ It can either be relaxed (‘r’) or strict (‘s’). When the DKIM signature is in relaxed mode, emails that share an organizational domain and a ‘from’ domain will pass DMARC checks. However, in strict mode, these two must be an exact match.
  • aspf: this is a tag that sets the alignment mode for SPF. Again, it can be either relaxed or strict.
  • ri: this tag refers to the reporting frequency for how often you want to receive XML reports. You can set this based on your preferences so that the ISP will send the report at different times daily.


Author image

Igor Rendulic

  • Salt Lake City
Explorer, developer, ... Using this website as the bookmarking service for the things that might become useful in the future.
You've successfully subscribed to Igor Technology
Great! Next, complete checkout for full access to Igor Technology
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.