SPF, DKIM and DMARC: Email Security Setup Guide

Anyone can send an email that claims to come from your domain unless you tell the world's mail servers otherwise. Fake invoices, fake payment change requests and fake HR notices sent in a company's name are among the most common frauds Indian businesses face. This SPF DKIM DMARC setup guide explains the three DNS records that stop most of this spoofing and how to put them in place without breaking your genuine email.

There is a second reason to act. Large mailbox providers now check these records before accepting mail. Since February 2024, Google and Yahoo have required bulk senders, those sending around 5,000 or more messages a day to their users, to authenticate mail with SPF, DKIM and DMARC. Microsoft introduced similar rules for high-volume senders to its consumer mailboxes. Even if you send far less, missing records make it more likely that your quotations and invoices land in spam.

What SPF, DKIM and DMARC Each Do

• SPF (Sender Policy Framework): A DNS record listing the servers allowed to send mail for your domain.
• DKIM (DomainKeys Identified Mail): A digital signature added to every outgoing message. The receiving server checks it against a public key in your DNS to confirm the message was not altered and came from an authorised system.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): A policy that tells receivers what to do when a message fails SPF and DKIM checks, and where to send reports about it.

SPF and DKIM prove a message is authorised. DMARC ties them to the visible "From" address and enforces the result. You need all three.

Step 1: Inventory Every System That Sends Your Email

Most failed rollouts skip this step. Before touching DNS, list every service that sends mail using your domain. Typical entries for an Indian company include:

• Your main mail platform, such as Microsoft 365 or Google Workspace.
• ERP or accounting software that emails invoices.
• HRMS or payroll software that sends payslips.
• CRM, marketing and newsletter tools.
• Website contact forms and e-commerce platforms.
• Helpdesk and ticketing systems.
• Scanners, printers and on-premise applications that relay mail.

Ask each department what they use. The finance team's invoicing tool is the one most often forgotten.

Step 2: Set Up SPF Correctly

SPF is a single TXT record at the root of your domain. A simple example for a company using one mail provider and one invoicing service looks like this:

v=spf1 include:spf.yourmailprovider.com include:mail.invoicetool.com -all

Rules to follow:

1. Only one SPF record per domain. Two separate SPF records cause both to fail. Merge them into one.
2. Stay within 10 DNS lookups. The SPF standard limits evaluation to 10 DNS lookups. Each "include" and some other mechanisms count, including nested ones inside your providers' records. Exceed the limit and SPF returns a permanent error.
3. Choose the ending carefully. "-all" means reject anything not listed. "~all" means soft fail. Many teams start with "~all" and rely on DMARC for enforcement.
4. Remove old services. Delete includes for tools you no longer use. They waste lookups and widen the list of servers that can send as you.

Step 3: Enable DKIM Signing

DKIM is switched on inside each sending service, not only in DNS. The process is similar for most platforms:

1. In the admin console of the service, find the DKIM or domain authentication setting.
2. Generate a key. Choose a 2048-bit key where the service offers it.
3. Publish the public key in DNS as a TXT or CNAME record at the selector name the service gives you, for example selector1._domainkey.yourdomain.in.
4. Return to the console and turn signing on.
5. Send a test message and check the headers for "dkim=pass".

Repeat for every sending service in your inventory. Each one should sign with your domain, not only its own.

Step 4: Publish DMARC and Move to Enforcement

DMARC is a TXT record at _dmarc.yourdomain.in. Roll it out in stages.

Stage 1: Monitor

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.in

With p=none, nothing is blocked. Receivers send you daily aggregate reports showing which servers sent mail as your domain and whether each passed. Use a DMARC report tool to read them, because the raw XML is hard to review by hand.

Stage 2: Fix what fails

Review the reports for two to four weeks. For every legitimate sender that fails, fix its SPF include or DKIM signing. For sources you do not recognise, investigate. They may be forgotten tools or spoofing attempts.

Stage 3: Quarantine

Change the policy to p=quarantine. Failing mail goes to spam. Watch reports and user complaints for a few weeks.

Stage 4: Reject

Move to p=reject. Failing mail is refused outright. This is the goal, because it gives the strongest protection against spoofing of your exact domain.

Do not forget parked and unused domains. Publish an SPF record of "v=spf1 -all" and a DMARC policy of p=reject on any domain that never sends mail, so it cannot be used for fraud.

Step 5: Test, Document and Maintain

Email authentication is not a one-time project. Records drift as departments add new tools, vendors change their sending servers and staff leave. A short routine keeps the setup healthy.

• Test after every change. Send messages to test mailboxes on different providers and check the headers for spf=pass, dkim=pass and dmarc=pass.
• Keep a change log. Record every DNS change, who made it and why. This helps when something breaks months later.
• Add a step to vendor onboarding. Any new SaaS tool that sends mail in your name should be set up for SPF and DKIM before it goes live.
• Rotate DKIM keys periodically, following your mail provider's guidance.
• Restrict DNS access. Limit who can edit DNS records and turn on multi-factor authentication for your domain registrar account.

Common Mistakes to Avoid

• Stopping at p=none. A monitoring policy gives visibility but no protection. Plan the move to enforcement from the start.
• Multiple SPF records added by different vendors over time.
• Forwarding confusion. Forwarded mail often breaks SPF but keeps DKIM intact, which is why DKIM on every sender matters.
• Subdomains overlooked. Check whether marketing tools send from subdomains and cover them in your policy.
• No owner for reports. Assign someone in IT to review DMARC reports every month, even after reaching p=reject.
• Relying on authentication alone. These records protect your exact domain. Lookalike domains and compromised accounts need other controls, such as user awareness training and multi-factor authentication.

Frequently Asked Questions

What is the difference between SPF, DKIM and DMARC?

SPF lists which servers may send for your domain. DKIM signs each message so it can be verified. DMARC tells receivers what to do when checks fail and sends you reports.

How long does DMARC setup take?

Publishing the records takes minutes. Moving safely from p=none to p=reject usually takes several weeks to a few months, depending on how many services send mail for you.

Will DMARC stop all phishing?

No. It stops direct spoofing of your domain. It does not stop lookalike domains or attacks from compromised mailboxes.

Do small businesses need DMARC?

Yes. Invoice and payment fraud targets companies of every size, and authenticated mail is more likely to reach customers' inboxes.

How Affix Center Can Help

Our cybersecurity team can audit your current email records, build a sender inventory, configure SPF, DKIM and DMARC and guide you to enforcement without disrupting business mail. Through our IT operations and support services, we can also monitor DMARC reports and keep records updated as you add new tools.

To secure your domain against spoofing, get in touch with our team.