SPF, DKIM, DMARC: Configure Your Domain Step by Step

Your emails do not reach the inbox because you write well -- they reach it because receiving servers trust your domain. SPF, DKIM, and DMARC are the three DNS records that establish that trust, and misconfiguring any one of them quietly breaks the other two.

Why All Three Records Are Required

Each protocol solves a distinct problem.

SPF (Sender Policy Framework) declares which IP addresses are authorized to send email on behalf of your domain. The specification is defined in RFC 7208.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The recipient's server retrieves your public key from DNS and verifies the message was not modified in transit. The standard is RFC 6376.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It defines what happens when a message fails authentication and where reports should be sent. See RFC 7489.

A domain with SPF and DKIM but no DMARC has no enforcement policy -- spoofed messages from unlisted sources can still reach inboxes. A domain with DMARC but broken SPF or DKIM will see legitimate messages fail. The three records form a single system.

Setting Up SPF

How SPF Works

SPF is a TXT record published at your root domain. When a receiving server gets a message from you@yourdomain.com, it queries yourdomain.com for the SPF record and checks whether the sending IP is authorized.

Writing Your SPF Record

A concrete example:

v=spf1 ip4:203.0.113.10 include:smtp.infomaniak.com ~all

Each part:

• v=spf1 -- protocol version, always present and always first
• ip4:203.0.113.10 -- a specific IPv4 address your server sends from
• include:smtp.infomaniak.com -- inherits the SPF record published by your SMTP provider
• ~all -- softfail: messages from unlisted sources are accepted but flagged

If you send through your own SMTP server (OVH, Infomaniak, or a self-hosted instance), add its IP directly with ip4:. If your provider publishes its own SPF record, use include: instead of listing raw IPs.

The Double SPF Mistake

A domain can only have one SPF TXT record. If you publish two, most resolvers will reject both, and every message you send will fail SPF.

Wrong:

v=spf1 ip4:203.0.113.10 ~all
v=spf1 include:smtp.infomaniak.com ~all

Right:

v=spf1 ip4:203.0.113.10 include:smtp.infomaniak.com ~all

Merge all your sending sources into a single record. This is the most common SPF error, and it is entirely silent until you start checking your DMARC reports.

The all Qualifier

• -all (hardfail): reject messages from any unlisted source
• ~all (softfail): accept but mark them suspicious
• ?all (neutral): no opinion

Start with ~all while you confirm every legitimate sending source is listed. Once you are confident nothing is missing, switch to -all.

Setting Up DKIM

How DKIM Works

DKIM uses asymmetric cryptography. Your sending server signs each outgoing message with a private key. The corresponding public key is published in DNS. The recipient's server fetches the public key and validates the signature on arrival.

Publishing the DKIM Record

Your SMTP provider or email server generates the key pair and gives you the public key to publish. The DNS record:

Type:  TXT
Name:  mail._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

The mail prefix is the selector -- a label that lets you run multiple DKIM keys or rotate them without interrupting delivery. Common selectors include mail, default, or a date string like 2026q3.

Tag breakdown:

• v=DKIM1 -- version
• k=rsa -- key algorithm
• p=... -- Base64-encoded public key provided by your server

Key Length and Rotation

Use a minimum key length of 2048 bits. Some older configurations still generate 1024-bit keys; check your provider's settings and request 2048 if necessary.

Rotate keys periodically. Publish the new key under a new selector, update your server configuration, then wait a few days before removing the old selector to avoid failing messages still in transit.

Setting Up DMARC

How DMARC Works

DMARC evaluates the results of SPF and DKIM and applies a policy you control. For DMARC to pass, at least one of SPF or DKIM must also align with the domain in the visible From header -- not just any domain in the message headers.

Writing Your DMARC Record

Type:  TXT
Name:  _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;

Tag breakdown:

• v=DMARC1 -- version
• p=none -- policy (none, quarantine, or reject)
• rua=mailto:... -- destination for aggregate reports, sent daily
• fo=1 -- generate a forensic report when either SPF or DKIM fails

The Three DMARC Policies

The p=none Trap

p=none is the right starting point. It lets you collect reports and discover which sources send on your domain's behalf without risking legitimate mail. The mistake is never moving past it.

A domain stuck on p=none for months offers no protection against spoofing. The intended progression:

1. Publish p=none with a reporting address
2. Read the aggregate reports for two to four weeks
3. Confirm all legitimate senders appear in your SPF record and are signing with DKIM
4. Move to p=quarantine
5. Once reports show no unexpected sources, move to p=reject

p=reject is when DMARC actually protects your domain. If you stop at step four, you have done most of the work for none of the security benefit.

Correct authentication is also a prerequisite for any sending volume -- skipping it while you warm up a new email domain means you are building reputation on a foundation that receiving servers will not trust. It is also one of the clearest paths onto an email blacklist.

Verifying Your Records

After publishing, DNS propagation can take up to 48 hours. Verify with standard DNS queries:

For SPF:

dig TXT yourdomain.com

For DKIM (replace mail with your selector):

dig TXT mail._domainkey.yourdomain.com

For DMARC:

dig TXT _dmarc.yourdomain.com

If the record is missing, wait and retry. If it appears but authentication still fails, check that your sending server is actually applying the DKIM signature and sending from a listed IP. Google documents the expected record formats in its sender authentication guide.

How This Applies in Fluenzr

Fluenzr supports SMTP (OVH, Infomaniak, and any standard SMTP provider), Gmail OAuth, and Microsoft accounts. When you connect via SMTP, Fluenzr sends through your provider's infrastructure. Your SPF record must cover your provider's IP range, and your DKIM key must be generated through your provider's settings -- Fluenzr does not touch your DNS.

This means you keep full ownership of your domain's reputation. See the features page for details on how sending accounts and infrastructure are managed.

Key Takeaways

• SPF, DKIM, and DMARC each solve a different authentication problem; all three are required for the system to work.
• Publish exactly one SPF TXT record per domain -- a second record silently breaks both.
• Use a 2048-bit DKIM key minimum and rotate it periodically using a new selector.
• Start DMARC at p=none to collect reports, then advance to p=quarantine and then p=reject.
• DMARC reports reveal every source sending on your domain's behalf -- read them before changing policy.
• Verify all three records with dig after any DNS change.
• Correct authentication is a prerequisite for effective warming and long-term deliverability.

Ready to send from a properly authenticated domain? Create a free account on Fluenzr and connect your SMTP server in minutes. If you are ready to go paid, the code FOUNDING50 gives you 50% off any plan for life -- reserved for the first 50 paying customers.