How to Set Up SPF, DKIM and DMARC So Your Email Lands in the Inbox

You are probably here because a customer said your email went to spam, or because an inbox provider now asks for proof that your messages are genuine. Both problems point to the same fix: three small DNS records called SPF, DKIM and DMARC. This guide shows how to set up DMARC along with the other two.

You do not need to be a network engineer to add them. You need access to your domain's DNS settings, a list of the services that send email for you, and a little patience while you test. This guide explains what each record does, shows examples, and gives a safe order of work.

Why email authentication matters now

Anyone can type your address in the "From" line of an email. Without checks, a receiving server cannot tell your real message from a fake one. Scammers use this to send fake invoices that look like they come from real businesses. Inbox providers fight back by trusting authenticated mail more.

The rules are tighter than they were. Since February 2024, Google and Yahoo have asked senders to authenticate their mail, and the rules are firmest for bulk senders:

• Google asks all senders to set up SPF or DKIM. Senders that send more than 5,000 messages a day to Gmail accounts must set up SPF, DKIM and DMARC, and the From domain must align with the SPF or DKIM domain. Marketing messages must support one-click unsubscribe, and spam rates must stay below 0.30%. See Google's email sender guidelines.
• Yahoo asks bulk senders to set up SPF and DKIM and to publish a valid DMARC policy of at least p=none that passes. It also asks for a working one-click unsubscribe and a spam rate below 0.3%. See Yahoo's sender best practices.

A small business with a few mailboxes may be well under the bulk limit. Even so, the same records help your normal mail reach the inbox, and they protect your name from being faked. Review the official pages above now and then, because providers can change their rules.

SPF: who is allowed to send for your domain

SPF stands for Sender Policy Framework. It is a single TXT record at your domain that lists the servers and services allowed to send mail for it. A receiving server looks up the record and checks whether the sending server is on the list. The standard is RFC 7208.

A simple SPF record looks like this:

Type:  TXT
Host:  @
Value: v=spf1 include:spf.mailprovider.example ~all

Here is how to read it:

• v=spf1 marks the record as SPF version 1.
• include: adds the allowed senders of another service, such as your email host or your newsletter tool.
• ip4: or ip6: allows a specific address, for example ip4:203.0.113.10.
• ~all is a soft fail for everything else. -all is a hard fail. Many people start with ~all and move to -all once they are sure the list is complete.

Three rules cause most SPF problems:

1. Publish only one SPF record per domain. Two SPF records cause a permanent error. If you add a new sender, merge it into the existing record.
2. Stay within 10 DNS lookups. Mechanisms such as include, a, mx, exists and redirect each count toward a limit of 10 lookups. Past that, SPF returns an error and the check fails. The ip4, ip6 and all mechanisms do not count. Remove senders you no longer use.
3. Watch the length. A single TXT string is limited to 255 characters. Long records are split into several quoted strings, which most DNS panels handle for you.

The Titan values for your own domain are in the help center. Follow what are my DNS settings for Professional Email powered by Titan and the guide to add an SPF record.

DKIM: a signature on every message

DKIM stands for DomainKeys Identified Mail. Your email service adds a digital signature to the headers of each message it sends. It publishes the matching public key in your DNS. The receiver fetches the key and checks that the message was not changed on the way and that it came from a service you approved. The standard is RFC 6376.

The record lives at a name made from a "selector" that your provider gives you:

Type:  TXT
Host:  selector1._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Some providers give you a CNAME instead, which points to a key they manage and rotate for you:

Type:  CNAME
Host:  selector1._domainkey
Value: selector1.dkim.mailprovider.example

Do not make up a selector or key. Copy the exact values from your email provider's DNS instructions. If you use more than one service to send mail, such as your mailbox host and a newsletter tool, each one needs its own DKIM record with its own selector. Our help center explains how to add a TXT record and add a CNAME record.

DMARC: the policy and the reports

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It sits on top of SPF and DKIM. It does three jobs:

1. It tells receivers that a message passes only if SPF or DKIM passes and aligns with the domain in the visible From address.
2. It tells receivers what to do with messages that fail.
3. It asks receivers to send you reports so you can see who is sending mail in your name.

Alignment is the part people miss. SPF can pass for a service's own domain while the From address shows yours. Unless the domains line up, DMARC treats that as a failure. Using the service's custom-domain option for DKIM is the usual fix.

A starter DMARC record looks like this:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]

The tags mean:

• v=DMARC1 marks the record as DMARC.
• p= sets the policy for your domain.
• rua= is the address that receives daily aggregate reports.

The mailbox in rua must be one you can read. If you send reports to a mailbox on another domain, that domain must allow it. A dedicated address on your own domain is the simplest choice.

The three DMARC policies

Policy	What receivers do with failing mail	When to use it
p=none	Deliver it as normal and send you reports	The first step, while you learn who sends mail for you
p=quarantine	Treat it as suspicious, usually the spam folder	When reports show your real mail passes
p=reject	Refuse it	When you are confident every real sender is covered

Start with p=none. It does not block anything, so it is safe, and it meets the minimum policy Google and Yahoo ask of bulk senders. It is a monitoring step, not the end goal. A domain at p=none still lets scammers fake your address. Over time, move to quarantine and then reject to protect your name.

Step-by-step setup

Work in this order.

1. List every service that sends email as you. Your mailbox host, your newsletter tool, your online store, your invoicing software, your website contact form and any helpdesk tool. Missing one is the top reason real mail fails later.
2. Open your DNS settings. In your BetterMade account, use the guide to manage DNS records.
3. Publish or update SPF. One record, with an include: for each sender. Check you stay within 10 lookups.
4. Turn on DKIM for each sender. Copy the record from each service and add it.
5. Publish DMARC at p=none with an rua address you read.
6. Wait and read the reports. Give it two to four weeks so you see normal traffic, such as monthly mailings.
7. Fix what fails. Add forgotten senders, correct alignment, remove old ones.
8. Move to p=quarantine. Watch for problems for a few weeks.
9. Move to p=reject once real mail passes consistently.

Changes to DNS can take time to spread. Allow up to a day or two before you decide that a record is wrong.

How to test your setup

After you publish your records, check them:

• Send a test message from each service to a mailbox you can open at a large provider, then use the "show original" or "view source" option. Look for spf=pass, dkim=pass and dmarc=pass in the headers.
• Use a free DNS lookup tool to confirm the record text has no typos, such as a missing v= or a stray space.
• Confirm there is exactly one SPF record and one DMARC record.
• Send to a few different providers, not only one.

If a message bounces, the error text often tells you which check failed. The help center article on how to fix rejected email with a bounce error helps you read it.

Common mistakes and how to avoid them

• Two SPF records. Merge them into one.
• Too many lookups. Remove old include: entries or ask a sender for a flattened list.
• DMARC with no reports. A policy without rua is a policy you cannot learn from.
• Jumping straight to p=reject. Real mail from a forgotten sender will be refused.
• Forgetting subdomains. If you send mail from a subdomain, check its records too. The sp= tag sets the policy for subdomains.
• Leaving old senders in place. Each stale include: is a risk and a lookup.
• Never revisiting the setup. Add a reminder each time you start a new email tool.

Frequently asked questions

Do I need all three records?

Yes. SPF and DKIM prove a message is genuine in different ways, and DMARC ties them to your visible address and gives you reports. Google and Yahoo ask bulk senders for all three.

How long does it take to set up DMARC?

Publishing the records takes minutes. Reaching p=reject safely usually takes a few weeks, because you need time to read reports and fix any missed senders.

Will p=none stop spoofing?

No. It only monitors. To block fake mail, you need quarantine or reject.

I only send a few emails a day. Do I still need this?

It is still worth doing. Authentication helps your normal mail reach the inbox, protects your brand from being faked, and keeps you ready if your volume grows.

My email still goes to spam. What else can I check?

Authentication is only one factor. Message content, sending history and recipient behaviour also matter. See the help center article on email going to spam for more checks.

Does Professional Email set this up for me?

The DNS settings for Professional Email are in our help center, and our support team can help you add them.

Your next step

Start with a quick audit of who sends mail as your domain, then publish SPF, DKIM and a DMARC record at p=none. If you do not have business email yet, Professional Email gives you addresses on your own domain with plans starting at $4.99. Questions? Call BetterMade support on (480) 624-2500.