SPF, DKIM, DMARC, PTR, and BIMI Records: Complete Setup Guide

Five DNS-related records decide whether your mail reaches the inbox, gets filtered, or is rejected outright. SPF names your authorized servers, DKIM signs each message, DMARC enforces both, PTR proves your sending IP is legitimate, and BIMI puts your logo in the inbox. This guide covers what each one does, how to publish them, and how to verify they work.

What Do SPF, DKIM, DMARC, PTR, and BIMI Each Do?

They solve five different problems, which is why publishing only one leaves gaps.

SPF and DKIM are authentication mechanisms. DMARC is the policy layer that sits on top of them and provides reporting. PTR is an infrastructure prerequisite that has nothing to do with your domain’s DNS zone. BIMI is a display feature that only activates once the first four are in order.

An important detail that trips up experienced admins: SPF validates the envelope sender, also called the Return-Path, not the From: address your recipient actually sees. A message can pass SPF cleanly and still be a forgery of your brand. DMARC exists specifically to close that gap.

Why Do Gmail, Yahoo, and Outlook Require SPF, DKIM, and DMARC Now?

Because unauthenticated mail became a rejection condition rather than a reputation penalty.

Google’s sender guidelines require anyone sending more than 5,000 messages per day to Gmail accounts to publish SPF, DKIM, and a DMARC record of at least p=none, along with valid reverse DNS, TLS transmission, and spam complaint rates below 0.10% and avoid ever reaching a spam rate of 0.30% or higher. Yahoo adopted an equivalent standard on the same 2024 timeline.

Microsoft followed in 2025. Its announcement for high volume senders states that mail to Outlook.com, Hotmail.com, and Live.com from domains sending over 5,000 messages daily must pass SPF and DKIM and carry a DMARC record aligned with at least one of them. Non-compliant messages return 550 5.7.515 Access denied.

Below the 5,000 message threshold the rules are looser, but not by much. Gmail expects every sender to have SPF or DKIM configured, and mail without either now bounces with a 550-5.7.26 unauthenticated sender error. If you send transactional mail from a contact form, an ecommerce order confirmation, or a WordPress notification, you are a sender.

How Does SPF Verify Your Sending Servers?

SPF publishes a list of authorized sending sources as a single TXT record on your domain. When a receiving server accepts a connection, it looks up that record and compares the connecting IP against the list.

A typical cPanel-generated record looks like this:

v=spf1 +mx +a +ip4:198.51.100.10 ~all

Reading it left to right: +mx authorizes any server listed in your MX records, +a authorizes the IP your domain’s A record points to, +ip4: authorizes a specific address, and ~all applies a soft fail to everything else.

The final mechanism is the one worth thinking about:

• ~all (soft fail) tells receivers that unlisted sources are probably unauthorized but should still be accepted and marked. This is the safe starting point.
• -all (hard fail) tells receivers to reject unlisted sources outright. Use it only after you are certain every legitimate sending service is listed.

Two constraints from RFC 7208 cause most SPF failures in the field. First, a domain may publish only one SPF record. Two records produce a permanent error and the check fails entirely, even though both records look correct in isolation. Second, evaluating the record may trigger no more than 10 DNS lookups. Each include: counts, and a single third-party include: can consume several lookups internally. Stack Google Workspace, a marketing platform, a helpdesk, and a payment processor and you can blow the limit without realizing it.

Third-party senders each need their own include: mechanism. Add them inside your existing record rather than publishing a second one:

v=spf1 +mx +a include:_spf.google.com include:servers.mcsv.net ~all

How Does DKIM Prove a Message Was Not Altered in Transit?

DKIM attaches a cryptographic signature to the message header. Your mail server signs outgoing messages with a private key held on the server, and receivers fetch the matching public key from DNS to verify the signature.

The public key lives at a selector-based hostname. cPanel uses the selector default, so the record sits at default._domainkey.yourdomain.com and contains something like v=DKIM1; k=rsa; p=MIGfMA0GCSq....

Because the signature covers the message body and a defined set of headers, any modification in transit invalidates it. That property is what makes DKIM the more durable of the two authentication methods. SPF breaks when a message is forwarded, since the forwarding server is not in your SPF record. DKIM survives forwarding as long as the message content is unchanged, which is why Google recommends aligning DMARC to DKIM when you have to choose one.

The private key stays on the server and should never be shared. cPanel exposes it in the interface for migration purposes, and treating that display as harmless is a mistake. Anyone holding your private key can sign mail that validates as yours. RFC 6376 covers the full specification if you need the mechanics behind key rotation.

How Does DMARC Tie SPF and DKIM Together?

DMARC does two jobs at once. It tells receiving servers how to handle mail that fails authentication, and it asks them to send you reports about what they saw.

A DMARC record is a TXT record published at _dmarc.yourdomain.com. Here is a practical starting record:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; pct=100

The tags defined in RFC 7489 that actually matter in production:

Older DMARC examples circulating online pair p=reject with sp=none, which enforces policy on your root domain while leaving every subdomain wide open for spoofing. Unless you have a specific reason to weaken subdomain handling, omit sp and let it inherit.

What Does DMARC Alignment Mean in Practice?

Alignment is the reason a message can pass SPF and still fail DMARC.

DMARC compares the domain in the visible From: header against the domain that SPF authenticated (the Return-Path) or the domain in the DKIM d= tag. If neither matches, the message fails DMARC regardless of how cleanly SPF or DKIM passed on their own. Google’s sender guidelines FAQ confirms that only one of the two needs to align, though aligning both is more reliable.

This is where email service providers cause problems. A marketing platform that sends with its own Return-Path domain will pass SPF against its domain, not yours. Unless that platform also signs with DKIM using your domain in the d= tag, your campaigns fail DMARC while your regular mail passes. Configure custom DKIM signing with any bulk sending platform you use, not just the SPF include.

Relaxed alignment (the default) accepts an organizational domain match, so mail.yourdomain.com aligns with yourdomain.com. Strict alignment requires an exact match. Start relaxed.

Why Does Reverse DNS (PTR) Matter for Email Delivery?

A PTR record maps an IP address back to a hostname. It is the reverse of an A record, and it is the one item in this guide that does not live in your domain’s DNS zone.

When your server connects to deliver mail, the receiving server performs a reverse lookup on the connecting IP. What it wants to see is a forward-confirmed result, described in RFC 1912: the IP resolves to a hostname, and that hostname’s A record resolves back to the same IP. Google’s sender guidelines list valid forward and reverse DNS as a requirement, not a suggestion.

Three things need to line up:

• The PTR record exists. An IP with no reverse DNS is treated as suspect by most large receivers, and some reject the connection before your message is evaluated.
• The lookup is forward-confirmed. A PTR pointing at mail.yourdomain.com is only useful if mail.yourdomain.com resolves back to that same IP.
• The HELO/EHLO hostname matches. Your mail server announces itself by hostname at the start of every SMTP conversation. When that name disagrees with the PTR record, receivers apply extra scrutiny.

Because PTR records live in the reverse DNS zone for the IP block, only the owner of that block can set them. That is your hosting provider, not you. Nothing in cPanel, WHM, or Zone Editor will change it.

On Shared Hosting and Reseller accounts, reverse DNS is configured on the shared mail IP and requires no action from you. On a VPS or dedicated server, the default PTR points at a generic server hostname. If you want it to match your own mail hostname, open a request with support with the IP and the exact hostname you want it to resolve to. Create the forward A record first, or the lookup will not confirm.

Check the current value with:

dig -x 198.51.100.10 +short

How to Add SPF, DKIM, and DMARC Records (Any DNS Provider)

All three records are ordinary TXT records. Use these names and values:

• SPF: Name = @ (or the root domain / blank, depending on the interface). Value = your single SPF string (for example v=spf1 +mx +a include:_spf.google.com ~all).
• DKIM: Name = selector._domainkey (for example default._domainkey or google._domainkey). Value = the public key string supplied by your mail system or ESP (v=DKIM1; k=rsa; p=...).
• DMARC: Name = _dmarc. Value = your DMARC string (for example v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; pct=100).

Recommended TTL while testing: 300–3600 seconds. Once the records are confirmed working, raise the TTL to 14400 or higher.

Most common providers accept these exactly the same way:

• Cloudflare: DNS → Records → Add record → Type TXT.
• AWS Route 53: Hosted zones → Create record → Record type TXT.
• Google Cloud DNS / Google Domains: Add record set → Type TXT.
• Azure DNS: Record sets → + Add → TXT.
• GoDaddy / Namecheap / most registrars: DNS Management → Add → TXT.

Always publish only one SPF record and only one DMARC record. Multiple records of either type cause permanent failures.

How Do You Add SPF and DKIM Records in cPanel?

When cPanel is the authoritative nameserver, both records are handled from the same interface.

1. Log in to cPanel and open Email Deliverability under the Email section.
2. Find the domain you want to configure and click Manage.
3. Review the status for each record. cPanel flags missing or malformed records automatically.
4. Click Install the Suggested Record for any record that is missing. cPanel writes it to the DNS zone for you.
5. If your DNS is hosted elsewhere, use the Copy button next to the suggested name and value, then add the record manually at your DNS provider.

If cPanel reports that it cannot verify the server as an authoritative nameserver for your domain, check where your DNS is actually managed. When your domain uses external nameservers such as Cloudflare or a registrar’s DNS, cPanel cannot write records for you and the copy-and-paste path is the correct one. cPanel’s own Email Deliverability documentation covers the interface in detail.

To customize the SPF record rather than accept the default, use the Customize option below the displayed value. On a VPS or dedicated server with root access, you can also work at the server level through WHM.

How Do You Add a DMARC Record in cPanel?

Recent cPanel versions surface DMARC inside Email Deliverability alongside SPF and DKIM, so check there first. If your server runs an older version, or you want a record with tags cPanel does not expose, use the Zone Editor:

1. In cPanel, open Zone Editor under Domains.
   
   
2. Click Manage next to your domain.
   
   
3. Click + Add Record.
   
   
4. Set Type to TXT.
5. Set Name to _dmarc. cPanel appends your domain automatically.
6. Set TTL to 14400 (four hours).
7. Paste your DMARC string into the Record field.
8. Click Add Record.

The record appears in the Zone Records list once saved. DNS changes can take up to 24 hours to propagate fully, though TXT record updates usually resolve much faster.

Point rua at a mailbox you will actually monitor. Aggregate reports arrive as compressed XML attachments and a busy domain can generate dozens per week, so a dedicated address is better than your primary inbox.

Which DMARC Policy Should You Start With, and How Do You Move to Reject?

Start at p=none. Always.

p=none is monitoring mode. It changes nothing about how your mail is handled while collecting reports on every source sending as your domain. Publishing p=reject before you know what those sources are is the fastest way to kill your own invoices, password resets, and CRM notifications.

A workable progression:

• Weeks 1 to 4, p=none. Collect aggregate reports. Build a list of every IP and service sending as your domain, including ones you forgot about.
• Weeks 5 to 8, fix alignment. Add missing SPF includes, configure DKIM signing on third-party platforms, and retire any sender you cannot authenticate.
• Weeks 9 to 12, p=quarantine; pct=25. Raise pct toward 100 as reports stay clean. Failing mail goes to spam rather than disappearing, so mistakes are recoverable.
• After that, p=reject. Failing mail is refused at the server. Only go here when reports show consistent alignment across every legitimate source.

Domains that never send mail at all should publish p=reject immediately. A parked domain with no legitimate senders has nothing to break and is a favorite target for spoofing.

How Do You Read DMARC Aggregate Reports?

Aggregate reports are XML files sent daily by participating receivers. Each one lists sending IPs, message volume, and the SPF and DKIM results with alignment status.

Reading them raw is possible but tedious. What you are looking for:

• Sources you recognize that are failing. These are configuration gaps. A missing SPF include or unconfigured DKIM on a legitimate platform.
• Sources you do not recognize that are passing. Investigate immediately. Something is sending authenticated mail as your domain.
• Sources you do not recognize that are failing. Usually spoofing attempts, and evidence that tightening your policy is working.

A hosted DMARC reporting service parses the XML into readable dashboards and is worth the cost once you handle meaningful volume. For Gmail specifically, Google Postmaster Tools adds reputation and spam rate data that DMARC reports do not include.

What Is BIMI and When Is It Worth Setting Up?

BIMI (Brand Indicators for Message Identification) displays your brand logo beside your messages in supporting inboxes. It is the payoff for reaching DMARC enforcement rather than a separate deliverability lever.

Be clear about what it does not do. BIMI does not improve inbox placement. It is a visual trust signal that appears only after everything else already passes, and a broken BIMI setup costs you the logo, not the delivery.

Five things must be true at the same time, per the BIMI Group specification:

• DMARC at enforcement. Your policy must be p=quarantine or p=reject with pct=100. A p=none record does not qualify, and a partial pct value stops the logo from appearing in Gmail.
• SPF and DKIM aligned across every sender. One misaligned marketing platform is enough to break logo display.
• An SVG Tiny PS logo. This profile is more restrictive than standard SVG. Square aspect ratio, no scripts, no external references, hosted over HTTPS.
• A VMC or CMC for Gmail. A Verified Mark Certificate requires a registered trademark. A Common Mark Certificate requires documented public use of the logo for at least 12 months and is the accessible path for businesses without a registration. DigiCert’s setup guide covers the validation process for both.
• A BIMI TXT record at default._bimi.yourdomain.com.

The record itself is short:

v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/cert.pem

Provider support is uneven, and that should shape your decision. Gmail, Apple Mail, Yahoo Mail, and Fastmail display BIMI logos. Outlook does not participate in the standard at all. Gmail requires at minimum a CMC and will ignore a self-asserted record, while only a VMC produces Gmail’s blue verified checkmark. Yahoo and Fastmail will display a self-asserted logo with no certificate, which makes a certificate-free BIMI record a reasonable first step if your audience skews that way.

Mark certificates carry an annual cost and a validation process measured in weeks. That expense makes sense for consumer-facing brands sending real volume, where impersonation is an active risk and the logo affects open rates. For a business sending a few hundred messages a month, the DMARC work is the part that matters and BIMI can wait.

Two operational habits prevent the most common BIMI failures. Set renewal reminders well ahead of certificate expiry, because an expired certificate removes your logo with no warning. And resubmit to your certificate authority whenever the logo changes, since a mismatch between the hosted SVG and the certificate breaks display just as completely as a DNS error.

What Are the Most Common SPF, DKIM, DMARC, PTR, and BIMI Mistakes?

These account for most of the deliverability tickets we see.

• Two SPF records on one domain. Often the result of adding a second record for a new service instead of merging the include. Both records become invalid.
• Exceeding the 10 DNS lookup limit. SPF returns a permanent error and every message fails the check. Flatten includes or drop unused services.
• DKIM record broken across lines. Some DNS interfaces split long TXT values incorrectly. Verify the published value matches the source exactly.
• p=reject published on day one. Legitimate mail from unrecognized sources starts bouncing immediately with no reports to diagnose it.
• No rua address. The record technically validates, provides zero visibility, and you learn nothing about who is sending as you.
• Forgetting the marketing platform. Campaign mail sends from different infrastructure than your cPanel mail server and needs its own authentication setup.
• Missing or unconfirmed reverse DNS. A PTR that does not resolve forward to the same IP is functionally the same as having none.
• BIMI published before DMARC reaches enforcement. The record validates, the certificate is paid for, and the logo never appears.
• A standard SVG used for BIMI. Exported logos from design tools rarely meet the SVG Tiny PS profile without conversion.
• Publishing records at the wrong DNS provider. Always check the authoritative nameservers first.

How Do You Confirm Your Records Are Working?

Check DNS first, then check an actual delivered message.

From a terminal:

dig +short TXT yourdomain.com
dig +short TXT default._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT default._bimi.yourdomain.com
dig -x 198.51.100.10 +short

Each TXT lookup should return exactly one relevant record. Two SPF records or two DMARC records mean something needs to be removed. The reverse lookup should return a hostname that resolves back to the same IP.

Then send a test message to a Gmail address. Open it, click the three dot menu, and select Show original. The header summary reports SPF, DKIM, and DMARC results directly. All three should read PASS. If DMARC shows FAIL while SPF and DKIM pass, you have an alignment problem, not an authentication problem.

Public tools such as MXToolbox will validate record syntax and flag SPF lookup count issues. A dedicated BIMI validator is worth running separately, since it checks the SVG profile and certificate chain that a general DNS tool will not inspect.

When Should You Bring In Support?

Publishing SPF, DKIM, and DMARC is a task most site owners can complete in twenty minutes. Diagnosing why mail still lands in spam afterward is a different job.

Handle it yourself when you are adding records to a domain with a small number of known senders, or adding an SPF include for a service you just signed up for.

Contact our support team when mail from your domain is being rejected outright, when DMARC reports show authenticated mail from a source you cannot identify, or when you need a PTR record set on a VPS or dedicated server IP. Reverse DNS and Exim configuration require access that cPanel does not expose, and reverse DNS in particular can only be changed by the owner of the IP block.

For agencies running authentication across a portfolio of client domains, or businesses where email interruption has direct revenue impact, Managed Hosting covers ongoing configuration and monitoring rather than one-time setup.

Every InMotion Hosting plan includes 24/7 access to trained technicians who complete over 280 hours of instruction before handling Tier 1 tickets. Email authentication questions are among the most common things we help with, and there is no charge to ask.