SPF, DKIM and DMARC for a Sending Domain, Step by Step

Three DNS records decide whether your mail gets a chance with the recipient at all. SPF, DKIM and DMARC for a sending domain are not a set of optional extras, they are the minimum that every conversation about deliverability starts from. Each one covers a different piece of the same puzzle. SPF points at the servers authorised to send on behalf of the domain. DKIM adds a cryptographic signature confirming that the message was not swapped in transit. And DMARC ties both mechanisms to the From field and tells the filter what to do when something does not match.

Why a sending domain needs three records instead of one

Large receivers treat the full set as a precondition. Gmail, Microsoft, Yahoo, and in Poland also WP and Onet check authentication before they even look at the content. One element missing? You start from a worse position before you get a chance to prove anything.

Let us set expectations right away. Correct configuration does not guarantee the Inbox folder. It confirms the sender’s identity – the rest is decided by domain reputation, IP address reputation and how recipients react to your messages. Authentication opens the gate. It does not walk you to the primary inbox by the hand.

There is one more argument that few people mention at the implementation stage: without DMARC you have no visibility into who is impersonating your domain. You do not know how many messages go out with addresses in your domain from servers you never authorised. Aggregate reports turn guesswork into a list of specific sources.

Preparation: sending subdomain, Return-Path and PTR

Use a subdomain for bulk sending. mail.yourcompany.com or news.yourcompany.com, never the main domain that your invoices and sales correspondence go out from. The reason is purely practical: reputation follows the domain. When the newsletter takes a hit at a large filter, transactional and company mail keeps working.

Return-Path, that is the envelope sender or MAIL FROM, is the address that is not visible in the mail client but decides bounces and the SPF result. It has to belong to your domain, not to the sending platform’s domain. Otherwise SPF will come out positive, but DMARC alignment will not work and the whole construction falls apart. This is the point that gets skipped most often of all.

PTR, the reverse DNS of the sending server’s IP address, has to resolve to a name that points back to the same IP. On our side we set this up across the fleet – the client touches nothing here. On the subdomain you also need MX and A records, so you can receive bounces and replies to the address in the From field.

Tip: lower the TTL to 300-600 seconds a few hours before making changes. Corrections then take effect in minutes instead of half a day. Once the configuration is stable, raise the value back.

Step 1: SPF without exceeding the DNS lookup limit

SPF is a TXT record starting with v=spf1. Then come the mechanisms: include, ip4, ip6, a, mx. At the end the policy – -all or ~all. One domain, exactly one SPF record. Two entries is a permanent error, not a warning; they have to be merged into one.

The most dangerous thing is the limit of ten DNS lookups. Every include counts, and so does every a, mx and ptr. Going over gives a permerror, and a filter treats permerror exactly the same as SPF missing entirely. A domain with a seemingly correct record stops passing authentication overnight.

How to get under the limit:

• remove includes for tools you no longer use – they usually hang there for years,
• flatten to ip4 where the provider has a stable and documented address pool,
• split systems across separate subdomains, each with its own record,
• skip the ptr mechanism, obsolete and eating a lookup for nothing.

Tighten the policy in stages. For testing ~all is enough. Move to -all only once you have confirmed that every sending source made it into the record. If part of your sending goes through a CRM or a shop, review the list of available integrations with external systems and add to the record only the ones you actually use.

Tip: count the lookups before adding another include. The most common cause of a sudden loss of authentication is one entry too many, thrown in by another department without consulting anyone.

Step 2: DKIM, the signature that survives forwarding

DKIM signs selected headers and the body with a private key. The recipient fetches the public key from a TXT record under the name selector._domainkey.yourdomain.com and verifies the signature. If anything along the way touched the signed fields, verification fails.

By default pick a 2048-bit key. It happens that a DNS panel will not accept such a long value in a single string – in that case split it into quoted strings instead of dropping down to 1024. Shortening the key to suit the editor is a bad trade.

Selectors and key rotation

One selector per sending system. A name with the system or the date, for example mc2026a, makes later rotation simpler. The rotation itself runs without a break in signing: you publish the new selector, switch signing to the new key, and after a few days delete the old record.

DKIM has one advantage over SPF that can save a campaign. The signature survives message forwarding, because it travels along with the headers. SPF falls apart on a forward, because the forwarding server does not appear in your record. That is why DMARC accepts alignment on either side.

The implementation mistake we see most often: the key value copied from the panel together with spaces and newline characters. The record looks correct, and the signature does not verify at all.

Step 3: DMARC from p=none to p=reject without cutting off your own mail

DMARC is a TXT record under _dmarc.yourdomain.com. It contains v=DMARC1, the policy p, the report addresses rua and ruf, optionally pct, and the alignment modes adkim and aspf.

The core of it is alignment. The domain in the From field has to match the domain in Return-Path or the domain of the DKIM signature. A positive SPF on its own gives you nothing if Return-Path points at the platform’s domain. Relaxed mode allows a subdomain, strict requires an exact match – start with relaxed.

Run the rollout in stages:

1. p=none with an rua address, for a few weeks, with no effect on delivery,
2. analysis of the aggregate reports and filling in the missing sources,
3. p=quarantine with a gradually rising pct,
4. p=reject only after the sender list has been cleaned up.

The rua reports are the only reliable source of knowledge about who sends on your behalf. Systems nobody remembered any more come out of them regularly: a CRM, a shop, an invoicing plugin, the accounting office. The ruf forensic reports contain fragments of messages, so with GDPR in the background we treat them carefully and by default leave rua alone.

And do not jump straight to p=reject on the domain your company mail goes out from. First count the sources, then decide when to tighten the policy from p=none to quarantine and reject.

Verification and the typical mistakes we see during rollouts

Start the check from the console. dig TXT on the domain, on the DKIM selector and on _dmarc. Then a practical test: a message to a Gmail and a Microsoft mailbox, view the original, read the headers. In the Authentication-Results field you are looking for three results – spf=pass, dkim=pass, dmarc=pass – together with the alignment information.

The list of faults that keep coming back during migrations:

• two SPF records on one domain,
• permerror from exceeded DNS lookups,
• a DMARC record published under the wrong name, without the _dmarc prefix,
• a DKIM selector on the main domain instead of the sending one,
• no PTR for the server’s IP address,
• Return-Path left on the provider’s domain.

Before you write a change off as failed, check the TTL of the previous entry. An old record can sit in resolver caches long after you swapped the value in the panel.

Tip: after every record change send a test message to your own accounts at several large providers and go through the headers. Only then launch a campaign to the list.

Authentication is a precondition, not the whole of deliverability

Three correct records let you through the gate. The destination folder is decided by domain reputation and IP address reputation. A new domain and a new IP need a warmup: small volumes at the start, growth day by day, the most engaged recipients first.

From the experience of running our own fleet of sending servers: when a large filter blocks you, the speed of the reaction is what counts. We pause sending from that IP, clean the list of hard bounces, get in touch through the operator’s form, and then go back to volume slowly. Very slowly. Yanking the traffic around after being unblocked ends in a second block.

List hygiene runs in parallel. Remove hard bounces immediately, handle complaints without delay, make unsubscribing one click away with a List-Unsubscribe header. Consent here is a technical requirement, not only a legal one – GDPR and article 398 of the PKE, the Polish electronic communications law, require it in B2B as well, and a list built on consent simply delivers better.

No DNS configuration gets around the filters. If someone promises you that, they are selling you a problem for later. We run configuration and maintenance together with our clients in our email marketing platform with its own fleet of sending servers, where domain authentication and DMARC reports are part of the standard account setup.

Summary: the rollout order in short

1. Split off a sending subdomain.
2. Set PTR and Return-Path in your own domain.
3. Build one SPF record below the lookup limit.
4. Generate a 2048-bit DKIM key with your own selector.
5. Publish DMARC with p=none and an rua address.
6. Analyse the reports and fill in the sources.
7. Tighten the policy to quarantine, then reject.
8. Run the domain and IP warmup.

Got an hour and want to know where you stand? Check two things: how many SPF records your domain has, and whether _dmarc exists at all. Those are the two most common places where everything stops.

Configuration is a one-off job, maintenance is continuous. Read the DMARC reports every month, rotate the DKIM keys, and keep the new systems added to SPF under control. When migrating to your own sending domain we go through these steps together with the client – get in touch if you want to do it once and properly.