{"id":61,"date":"2026-09-02T16:25:43","date_gmt":"2026-09-02T16:25:43","guid":{"rendered":"https:\/\/www.tkwebhosts.com\/blog\/how-to-configure-spf-dkim-dmarc\/"},"modified":"2026-09-02T16:52:20","modified_gmt":"2026-09-02T16:52:20","slug":"how-to-configure-spf-dkim-dmarc","status":"publish","type":"post","link":"https:\/\/www.tkwebhosts.com\/blog\/how-to-configure-spf-dkim-dmarc\/","title":{"rendered":"How to Configure SPF, DKIM and DMARC for Email Deliverability"},"content":{"rendered":"

By the TK WebHosts Web Team<\/a> \u00b7 Last reviewed 2 September 2026<\/p>\n

Email was designed without any way of proving who sent a message. Nothing in the original protocol stops a server anywhere on the internet from sending mail that claims to come from any domain it likes. Every anti-spoofing mechanism in use today is a layer added afterwards, and all three of the important ones are published the same way: as DNS records on the domain being protected.<\/p>\n

That is the practical point. SPF, DKIM and DMARC are not settings inside a mail client or features of a mail provider. They are public statements, made in DNS, about who is allowed to send as a domain and what should happen to anything that fails the test. Configuring them means editing a DNS zone, and getting them wrong means either that spoofing stays possible or that legitimate mail starts disappearing.<\/p>\n

Since February 2024, this stopped being optional for anyone sending at volume. Google and Yahoo both began requiring bulk senders \u2014 those sending more than 5,000 messages a day to their users \u2014 to publish SPF, DKIM and<\/strong> a DMARC policy, with the From: header aligned to one of the authenticated domains. Microsoft applied comparable requirements to Outlook.com addresses from May 2025. Domains that do not authenticate now get rejected or filtered by the largest mailbox providers on the internet as a matter of published policy.<\/p>\n

What follows is what each record proves, the exact syntax, where each one goes, and the order to roll them out in without breaking anything.<\/p>\n

If the underlying DNS concepts are unfamiliar, what a DNS record is and how one works<\/a> covers the foundation this article assumes.<\/p>\n

The three records answer three different questions<\/h2>\n

They are routinely discussed as a set, which obscures the fact that each proves something the other two cannot.<\/p>\n

\n\n\n\n\n\n\n\n
Record<\/th>\nThe question it answers<\/th>\nWhere it is published<\/th>\nSurvives forwarding<\/th>\n<\/tr>\n<\/thead>\n
SPF<\/strong><\/td>\nIs the server that sent this authorised to send for this domain?<\/td>\nTXT at the domain root<\/td>\nNo<\/td>\n<\/tr>\n
DKIM<\/strong><\/td>\nWas this message actually signed by the domain, and unaltered since?<\/td>\nTXT or CNAME at <selector>._domainkey.<domain><\/code><\/td>\nUsually<\/td>\n<\/tr>\n
DMARC<\/strong><\/td>\nWhat should a receiver do when the first two fail, and who should be told?<\/td>\nTXT at _dmarc.<domain><\/code><\/td>\nNot applicable \u2014 it is policy<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

DMARC is the one that has teeth, but it is worthless on its own: it is an instruction about the results of SPF and DKIM, so it has nothing to act on until both exist.<\/p>\n

Before touching DNS: the sending inventory<\/h2>\n

The single largest cause of authentication going wrong is not syntax. It is publishing a policy before knowing everything that sends mail as the domain.<\/p>\n

Most organisations send from more places than they think. A typical list runs to five or six: the mailbox provider, a marketing platform, an invoicing or accounting system, a helpdesk, a website’s contact form, and a CRM. Each has its own sending servers, and every one of them has to be authorised before any enforcing policy goes live.<\/p>\n

Write the list down first. Everything below depends on it being complete.<\/p>\n

SPF: authorising the servers that may send<\/h2>\n

SPF \u2014 Sender Policy Framework<\/strong> \u2014 publishes a list of the servers permitted to send mail for a domain. A receiving server compares the connecting server against that list and gets a pass, a fail, or something in between.<\/p>\n

The record<\/h3>\n

SPF is a TXT record published at the root of the domain<\/strong> \u2014 the name shown as @<\/code> in most control panels. A minimal one:<\/p>\n

v=spf1 include:_spf.google.com -all<\/code><\/p>\n

Read left to right: SPF version 1, authorise everything Google’s _spf.google.com<\/code> record authorises, fail everything else.<\/p>\n

A record covering several senders:<\/p>\n

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:mail.provider.net -all<\/code><\/p>\n

The parts<\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n
Term<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
v=spf1<\/code><\/td>\nVersion. Required, and must come first<\/td>\n<\/tr>\n
ip4:<\/code> \/ ip6:<\/code><\/td>\nAuthorise a specific address or CIDR range<\/td>\n<\/tr>\n
include:<\/code><\/td>\nAuthorise everything another domain’s SPF record authorises<\/td>\n<\/tr>\n
a<\/code><\/td>\nAuthorise the domain’s own A record address<\/td>\n<\/tr>\n
mx<\/code><\/td>\nAuthorise the servers listed in the domain’s MX records<\/td>\n<\/tr>\n
-all<\/code><\/td>\nFail everything not matched above<\/td>\n<\/tr>\n
~all<\/code><\/td>\nSoft fail \u2014 treat as suspicious but do not reject<\/td>\n<\/tr>\n
?all<\/code><\/td>\nNeutral \u2014 no assertion at all<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Four rules that decide whether it works<\/h3>\n

One SPF record per domain, without exception.<\/strong> Two TXT records both beginning v=spf1<\/code> do not combine. They produce a permanent error, and the practical result is that SPF fails altogether. Adding a sender means editing the existing record, never adding a second one. This is the most common SPF fault in the wild.<\/p>\n

Ten DNS lookups, maximum.<\/strong> The include<\/code>, a<\/code>, mx<\/code>, ptr<\/code>, exists<\/code> and redirect<\/code> terms each cost a DNS lookup, and nested includes count too \u2014 a single include:<\/code> of a provider that itself includes three others spends four. Exceed ten and the result is a permanent error and a failed check, no matter how correct the record looks. ip4:<\/code>, ip6:<\/code> and all<\/code> cost nothing, which is why replacing an include with the explicit ranges it resolves to \u2014 flattening \u2014 is the standard remedy. The trade-off is real: flattened records go stale silently when a provider changes its infrastructure. The specification also asks that no more than two lookups return nothing at all, so includes pointing at records that no longer exist are a liability of their own.<\/p>\n

SPF checks the envelope, not the visible From: address.<\/strong> The check runs against the MAIL FROM<\/code> address \u2014 the Return-Path \u2014 which is the address bounces return to, and which is frequently the sending platform’s domain rather than the visible one. A marketing platform can therefore pass SPF perfectly while the recipient sees a completely different domain in the From: field. This gap is precisely what DMARC alignment exists to close, and it is why SPF alone has never been sufficient.<\/p>\n

SPF does not survive forwarding.<\/strong> When a recipient auto-forwards a message, the forwarding server becomes the sender, and it is almost certainly not on the original domain’s authorised list. SPF fails on the forwarded copy through no fault of the configuration. This is not a defect to fix \u2014 it is the structural reason DKIM is needed as well.<\/p>\n

Choosing the closing mechanism<\/h3>\n

-all<\/code> is the correct end state. It is also the mechanism that rejects legitimate mail from any sender omitted from the inventory.<\/p>\n

The safe order is to publish with ~all<\/code> while confirming from real report data that every legitimate source passes, then tighten to -all<\/code> once the list is provably complete. Starting at -all<\/code> on an incomplete inventory produces exactly the outcome the exercise was meant to prevent, and the mail lost in the meantime is rarely noticed until someone asks why an invoice never arrived.<\/p>\n

DKIM: signing the message itself<\/h2>\n

DKIM \u2014 DomainKeys Identified Mail<\/strong> \u2014 takes a different approach. Rather than describing which servers may send, it proves the domain actually signed a specific message and that the signed parts have not been altered since.<\/p>\n

It works on a key pair. The private key sits on the sending mail server and signs a hash of the message body and a selected set of headers. The matching public key is published in DNS. A receiving server reads the signature, fetches the public key, and verifies the two agree.<\/p>\n

The record<\/h3>\n

DKIM is published at a name built from a selector<\/strong>:<\/p>\n

<selector>._domainkey.<domain><\/code><\/p>\n

For a selector of s1<\/code> on example.com<\/code>, the record name is s1._domainkey.example.com<\/code>. The selector is chosen by the sending provider and appears inside every signature it generates, which is how a receiver knows which key to fetch.<\/p>\n

The value, published as TXT:<\/p>\n

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA...<\/code><\/p>\n

Selectors are the reason multiple providers can sign for one domain at the same time. A mailbox provider on google._domainkey<\/code> and a marketing platform on mktg._domainkey<\/code> coexist without conflict, each holding its own key.<\/p>\n

CNAME is usually the better option<\/h3>\n

Many providers publish DKIM as a CNAME<\/strong> pointing at a key they host, rather than a TXT record holding the key itself:<\/p>\n

s1._domainkey.example.com<\/code> \u2192 s1.dkim.provider.net<\/code><\/p>\n

This is worth accepting whenever it is offered. It lets the provider rotate the underlying key without anyone editing DNS, which in practice means the key actually gets rotated rather than sitting untouched for years.<\/p>\n

Key length and the 255-character trap<\/h3>\n

Use 2048-bit<\/strong> keys. The specification sets 1024 as the floor and 2048 as the recommendation, and 1024-bit keys are increasingly treated as weak.<\/p>\n

A 2048-bit public key does not fit in a single DNS string, because a TXT record is limited to 255 characters per string. Longer values are published as several quoted strings that resolvers join back together. Most control panels handle the split automatically; some do not, and a record split at the wrong point resolves to a key that looks present in the panel and fails every verification. If DKIM fails immediately after publishing a 2048-bit key, this is the first thing to check.<\/p>\n

What breaks a valid signature<\/h3>\n

DKIM survives ordinary forwarding, which is its main advantage over SPF. It does not survive modification of the signed content. A mailing list that appends a footer or prefixes the subject line invalidates the signature it passes through, which is why discussion lists routinely break authentication for perfectly legitimate messages.<\/p>\n

DMARC: the policy that ties the two together<\/h2>\n

DMARC \u2014 Domain-based Message Authentication, Reporting and Conformance<\/strong> \u2014 is a DNS record like the others, but its payload is a policy rather than an address. Instead of describing infrastructure, it instructs receiving providers what to do with mail claiming to be from the domain that fails the checks, and asks them to report back on what they saw.<\/p>\n

Where it goes<\/h3>\n

A DMARC record is published at _dmarc.<domain><\/code>, not at the domain root.<\/strong> For example.com<\/code> the record name is _dmarc.example.com<\/code>.<\/p>\n

This is the single most common DMARC configuration failure. Published at the root, the record is syntactically valid, visible in the control panel, and completely inert, because nothing ever queries that name for a policy.<\/p>\n

The record<\/h3>\n

A starting policy:<\/p>\n

v=DMARC1; p=none; rua=mailto:dmarc@example.com;<\/code><\/p>\n

An enforcing one:<\/p>\n

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com;<\/code><\/p>\n

The tags<\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Tag<\/th>\nPurpose<\/th>\nNotes<\/th>\n<\/tr>\n<\/thead>\n
v=DMARC1<\/code><\/td>\nVersion<\/td>\nRequired, must be first<\/td>\n<\/tr>\n
p=<\/code><\/td>\nPolicy for the domain<\/td>\nRequired, must be second. none<\/code>, quarantine<\/code> or reject<\/code><\/td>\n<\/tr>\n
sp=<\/code><\/td>\nPolicy for subdomains<\/td>\nDefaults to the value of p=<\/code> if omitted<\/td>\n<\/tr>\n
rua=<\/code><\/td>\nWhere to send aggregate reports<\/td>\nThe tag that makes DMARC useful<\/td>\n<\/tr>\n
ruf=<\/code><\/td>\nWhere to send failure reports<\/td>\nLargely vestigial \u2014 see below<\/td>\n<\/tr>\n
adkim=<\/code><\/td>\nDKIM alignment mode<\/td>\nr<\/code> relaxed (default) or s<\/code> strict<\/td>\n<\/tr>\n
aspf=<\/code><\/td>\nSPF alignment mode<\/td>\nr<\/code> relaxed (default) or s<\/code> strict<\/td>\n<\/tr>\n
pct=<\/code><\/td>\nPercentage of failing mail the policy applies to<\/td>\nBeing removed from the specification<\/td>\n<\/tr>\n
ri=<\/code><\/td>\nAggregate report interval, in seconds<\/td>\nDefaults to 86400. Most receivers send daily regardless<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The three policies<\/h3>\n

p=none<\/code><\/strong> \u2014 take no action on failures, but send reports. Nothing changes about how mail is treated; the value is entirely in the visibility. This is where every deployment starts.<\/p>\n

v=DMARC1; p=none; rua=mailto:dmarc@example.com;<\/code><\/p>\n

p=quarantine<\/code><\/strong> \u2014 treat failing mail as suspicious, in practice by filing it in the junk folder.<\/p>\n

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com;<\/code><\/p>\n

p=reject<\/code><\/strong> \u2014 refuse failing mail outright, at the point of delivery. This is the end state, and the only policy that actually stops a domain being spoofed.<\/p>\n

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;<\/code><\/p>\n

Alignment is the part that matters<\/h3>\n

DMARC does not simply ask whether SPF or DKIM passed. It asks whether the domain that passed is the same domain the recipient sees in the From: field<\/strong>. That is alignment, and it is the concept that makes the whole mechanism coherent.<\/p>\n

A message passes DMARC if either<\/strong> of these is true:<\/p>\n

    \n
  1. SPF passes and<\/strong> the Return-Path domain aligns with the From: domain<\/li>\n
  2. DKIM passes and<\/strong> the signing domain in the signature aligns with the From: domain<\/li>\n<\/ol>\n

    Only one is needed. This is deliberate: it means a forwarded message that fails SPF can still pass DMARC on its intact DKIM signature.<\/p>\n

    Alignment has two modes. Relaxed<\/strong> \u2014 the default \u2014 requires only that the organisational domains match, so a Return-Path of bounce.example.com<\/code> aligns with a From: of example.com<\/code>. Strict<\/strong> requires an exact match, and rejects that same pair.<\/p>\n

    The practical consequence is the one that catches people out. A marketing platform sending with its own Return-Path passes SPF against its<\/em> domain, not the customer’s. SPF is green, DMARC still fails, and the message is treated as unauthenticated. The fix is either a custom Return-Path on the sending domain, or a properly configured DKIM signature with d=example.com<\/code>. This is why “SPF is passing, so why is DMARC failing?” is such a common question, and why the answer is almost always alignment.<\/p>\n

    The reporting tags, honestly<\/h3>\n

    rua=<\/code> is the reason to deploy DMARC at all before enforcing anything. It asks every participating receiver to send a daily XML summary of the mail they saw claiming to be from the domain, and how it authenticated. That data is what turns the sending inventory from a guess into a fact, and it is the only reliable way to discover the forgotten invoicing system before a policy starts rejecting it.<\/p>\n

    ruf=<\/code> \u2014 failure reports, sometimes called forensic reports \u2014 asks for a copy of individual failing messages. It should be understood as largely dead. Google, Microsoft and Yahoo do not send them, primarily for privacy reasons, since the reports contain recipient data. A record can carry ruf=<\/code> harmlessly, but it should not be relied on for anything, and a deployment plan that depends on failure reports is a plan built on data that will not arrive.<\/p>\n

    One detail that quietly breaks reporting: if the rua<\/code> address is on a different domain<\/strong> from the one being reported on, that other domain must authorise it by publishing a TXT record at <reporteddomain>._report._dmarc.<reportingdomain><\/code> containing v=DMARC1<\/code>. Without it, conforming receivers refuse to send the reports. Anyone collecting reports for several domains into one mailbox needs this, and its absence looks identical to nobody reporting.<\/p>\n

    The pct<\/code> tag, accurately<\/h3>\n

    pct=<\/code> was designed to apply the policy to a sample of failing mail during a phased rollout. It is widely misdescribed, including in most explanations of it.<\/p>\n

    v=DMARC1; p=reject; pct=60; rua=mailto:dmarc@example.com;<\/code><\/p>\n

    This does not<\/strong> mean 60% of failing mail is rejected and 40% is delivered untouched. It means 60% is rejected and the remaining 40% falls back to the next lower policy<\/strong> \u2014 quarantine, in this case. With p=quarantine; pct=60<\/code>, the other 40% falls back to none.<\/p>\n

    Two further cautions. Receiver support was always uneven, so the actual split is not dependable. And the tag is being removed in the revision of the DMARC specification working through the IETF. Treat pct<\/code> as legacy: the sound way to phase a rollout is to move the policy itself, deliberately, with report data justifying each step.<\/p>\n

    Do not forget subdomains<\/h3>\n

    If sp=<\/code> is omitted, subdomains inherit whatever p=<\/code> says, which is usually correct. Setting p=reject<\/code> without a matching sp=<\/code> is fine; setting p=none<\/code> leaves every subdomain unprotected, and non-existent subdomains are a favourite vector precisely because nobody monitors them. An explicit sp=reject<\/code> on a domain still testing at p=none<\/code> protects subdomains from day one at no risk to production mail, since nothing legitimate sends from them.<\/p>\n

    What MX records do, and do not do<\/h2>\n

    MX records are frequently pulled into these conversations and do not belong to this part of the system at all.<\/p>\n

    An MX record names the servers that accept mail sent to<\/strong> the domain. It carries a priority \u2014 a lower number meaning higher precedence \u2014 and it must point to a hostname with its own A or AAAA record, never to an IP address and never to a CNAME.<\/p>\n

    \n\n\n\n\n\n\n\n
    Provider<\/th>\nMX record<\/th>\n<\/tr>\n<\/thead>\n
    Google Workspace, current<\/td>\n1 smtp.google.com<\/code><\/td>\n<\/tr>\n
    Google Workspace, legacy set<\/td>\n1 aspmx.l.google.com<\/code>, plus four alt<\/code> records at priorities 5, 5, 10 and 10<\/td>\n<\/tr>\n
    TK WebHosts mail<\/td>\n10 pixel.tkwebhosts.com<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Both Google forms are valid and in service; the single-record version simply replaced the five-record set for new configurations.<\/p>\n

    The point to hold on to: MX is inbound only.<\/strong> It has no role in sending, and no role in SPF, DKIM or DMARC. Changing MX records does not affect whether outbound mail is authenticated, and does not fix mail landing in spam, because the MX record was never consulted on that journey.<\/p>\n

    The rollout order<\/h2>\n

    Sequence matters more than any individual record. This order gives visibility before enforcement, which is what makes it safe.<\/p>\n

      \n
    1. Inventory every sender.<\/strong> Every system that sends mail as the domain. This is the step that gets skipped and the step that causes the damage.<\/li>\n
    2. Publish SPF with ~all<\/code>.<\/strong> One record, at the root, covering every authorised sender, inside the ten-lookup limit.<\/li>\n
    3. Enable DKIM on every sending platform.<\/strong> A distinct selector for each. Prefer the CNAME form where the provider offers it, and use 2048-bit keys.<\/li>\n
    4. Publish DMARC at p=none<\/code> with rua=<\/code>.<\/strong> Nothing changes for recipients. Reports begin arriving within a day or two.<\/li>\n
    5. Read the reports for at least two weeks.<\/strong> Longer for a business with monthly or quarterly sending cycles. The objective is a full picture of every source, authenticating or not.<\/li>\n
    6. Fix what the reports expose.<\/strong> Usually a forgotten sender, and usually an alignment failure on a platform that passes SPF against its own Return-Path.<\/li>\n
    7. Move to p=quarantine<\/code>.<\/strong> Keep reading the reports.<\/li>\n
    8. Move to p=reject<\/code>, and tighten SPF to -all<\/code>.<\/strong> Only once the reports show every legitimate source authenticating and aligning.<\/li>\n<\/ol>\n

      Steps 5 and 6 are the ones under time pressure, and they are the ones that cannot be compressed. Everything before them is reversible; everything after them affects real mail.<\/p>\n

      Common configuration mistakes<\/h2>\n
      \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
      Mistake<\/th>\nWhat actually happens<\/th>\n<\/tr>\n<\/thead>\n
      Two SPF records on one domain<\/td>\nPermanent error. SPF fails entirely, rather than combining<\/td>\n<\/tr>\n
      More than ten DNS lookups in SPF<\/td>\nPermanent error. The record is correct and useless<\/td>\n<\/tr>\n
      DMARC published at the root instead of _dmarc<\/code><\/td>\nValid, visible, and never queried. No policy is in force<\/td>\n<\/tr>\n
      -all<\/code> before the inventory is complete<\/td>\nLegitimate mail rejected, usually noticed weeks later<\/td>\n<\/tr>\n
      Straight to p=reject<\/code> with no monitoring<\/td>\nMail lost with no report data to diagnose which source was missed<\/td>\n<\/tr>\n
      Assuming an SPF pass satisfies DMARC<\/td>\nIt does not, unless the Return-Path aligns with the From: domain<\/td>\n<\/tr>\n
      p=none<\/code> with no sp=<\/code><\/td>\nEvery subdomain left open to spoofing<\/td>\n<\/tr>\n
      A 2048-bit DKIM key split incorrectly<\/td>\nRecord present in the panel, verification fails every time<\/td>\n<\/tr>\n
      Relying on ruf=<\/code> for diagnostics<\/td>\nThe major receivers do not send failure reports<\/td>\n<\/tr>\n
      rua=<\/code> on another domain with no _report._dmarc<\/code> authorisation<\/td>\nConforming receivers silently decline to send reports<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

      How to verify<\/h2>\n

      Every record involved is publicly queryable, so verification costs nothing and should follow every change.<\/p>\n