SPF, DKIM, and DMARC are three DNS-based email authentication standards that work together to stop spoofing, phishing, and Business Email Compromise (BEC). SPF tells receiving servers which IP addresses are allowed to send mail for your domain. DKIM attaches a cryptographic signature to every outbound message so recipients can verify it has not been tampered with. DMARC ties both together with a policy—reject, quarantine, or none—and sends you forensic reports. Without all three configured correctly, anyone on the internet can send email that looks like it came from your domain. For Indian SMBs facing a surge in BEC attacks, getting these records right is not optional.
Why Indian SMBs Are Prime BEC Targets
Business Email Compromise is a straightforward fraud: an attacker sends email that appears to come from your CEO, CFO, or a trusted vendor, and instructs your finance team to transfer funds or share credentials. Indian small and mid-size businesses are disproportionately targeted for several reasons.
First, transaction volumes are growing. UPI and NEFT volumes have risen sharply, meaning finance teams are routinely processing large digital payments—exactly the transactions BEC targets. Second, many Indian SMBs rely on free or shared hosting plans that ship no email authentication out of the box. Third, vendor ecosystems are large and loosely governed: a mid-size manufacturer may deal with dozens of suppliers, each a potential spoofing target. Finally, impersonating a government body—GST department, MCA, SEBI—carries immediate authority in Indian business culture, and without DMARC, any domain can be spoofed for that purpose.
CERT-In has issued multiple advisories on email-based attacks, and the DPDP Act 2023 places an affirmative duty on data fiduciaries to implement technical safeguards. An unauthenticated email channel is a direct exposure.
SPF — Authorising Your Sending Sources
Sender Policy Framework (SPF) is a TXT record you publish in your domain's DNS. It lists every IP address or mail service authorised to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from you@yourcompany.in, it looks up your domain's SPF record and checks whether the sending IP is on the approved list.
A minimal SPF record looks like this:
v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.10 -allBreaking this down:
v=spf1— declares this as an SPF recordinclude:_spf.google.com— authorises Google Workspace's sending IPsinclude:amazonses.com— authorises Amazon SES if you send transactional mail through itip4:203.0.113.10— authorises a specific on-premise mail relay-all— hard fail: reject anything not on this list
Common SPF Mistakes
The most dangerous mistake is ending with ~all (soft fail) instead of -all (hard fail). Soft fail tells receivers to accept the mail and mark it as suspicious—most recipients never see that flag. Use -all in production.
The second most common error is exceeding ten DNS lookups. Each include:, a, mx, and ptr mechanism triggers a lookup. SPF evaluation fails with a permanent error if you exceed ten. Audit your record with a tool like MXToolbox and flatten nested includes into explicit IP ranges if you are over the limit.
v=spf1 record. Use a semicolon-separated comment in your DNS panel to track sources, not multiple records.DKIM — Signing Every Message You Send
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to your outgoing email headers. Your mail server signs each message with a private key. The corresponding public key is published as a DNS TXT record under a selector subdomain. Receiving servers fetch the public key, verify the signature, and confirm the message body and key headers have not been altered in transit.
The DNS record for a DKIM public key looks like this:
google._domainkey.yourcompany.in TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."The selector (google in the example above) is chosen by the sending service and tells the receiving server which key to look up. Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Amazon SES lets you choose your own.
What DKIM protects against: A malicious relay that intercepts your email and modifies the invoice amount or bank account number in the body. The DKIM signature will fail, and a DMARC-enforcing receiver will reject or quarantine the message.
What DKIM does not protect against: A lookalike domain attack where the attacker registers yourcompany-in.com and signs that domain's messages correctly. That is where DMARC alignment becomes essential.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanDMARC — Tying It Together With Policy and Reporting
Domain-based Message Authentication, Reporting and Conformance (DMARC) is published as another TXT record at _dmarc.yourdomain.in. It tells receiving mail servers what to do when SPF or DKIM fail, and where to send forensic reports.
A DMARC record looks like this:
_dmarc.yourcompany.in TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.in; ruf=mailto:dmarc-forensics@yourcompany.in; pct=100; adkim=s; aspf=s"Key tags:
p=quarantine— send failing messages to spam; usep=rejectonce you are confidentrua=— aggregate report recipient; a daily XML digest of pass/fail counts per sending sourceruf=— forensic report recipient; per-message failure reports (not all receivers send these)pct=100— apply the policy to 100% of messagesadkim=s— strict DKIM alignment: the signing domain must exactly match your From domainaspf=s— strict SPF alignment: the envelope sender must exactly match your From domain
DMARC Alignment — The Concept Most Teams Miss
DMARC alignment is the requirement that the domain authenticated by SPF or DKIM matches the domain in the From: header that users actually see. Without alignment enforcement, a spammer can pass SPF on a third-party relay domain while the From: header shows your company name.
In strict mode (adkim=s, aspf=s) the domains must match exactly. In relaxed mode (adkim=r, aspf=r) organisational domain matching is permitted—so mail.yourcompany.in aligns with yourcompany.in. Start with relaxed and tighten once your reports show only legitimate senders.
How a Receiving Server Evaluates Your Email — End to End
graph TD
A[Inbound Email Arrives at Receiver MX] --> B{SPF Check - sending IP authorised?}
B -->|Pass| C{DKIM Check - signature valid?}
B -->|Fail| D{DMARC Policy - none / quarantine / reject}
C -->|Pass| E{DMARC Alignment
From domain matches?}
C -->|Fail| D
E -->|Aligned| F[Message Delivered to Inbox]
E -->|Misaligned| D
D -->|p=none| G[Deliver + Send Report]
D -->|p=quarantine| H[Move to Spam + Send Report]
D -->|p=reject| I[Reject Message + Send Report]
F --> J[DMARC Aggregate Report Sent Daily]
G --> J
H --> J
I --> J
style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style D fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style F fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
style G fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style H fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style I fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style J fill:#1e3d2f,stroke:#10B981,color:#e2e8f0Email Authentication Adoption vs Attack Volume
xychart-beta
title "Global Email Auth Adoption vs Phishing Volume (2019–2024)"
x-axis ["2019", "2020", "2021", "2022", "2023", "2024"]
y-axis "Percentage / Index (base 100)" 0 --> 100
bar [22, 28, 35, 44, 54, 62]
line [41, 55, 68, 74, 80, 85]Bar: illustrative trend of DMARC enforcement adoption (p=quarantine or p=reject). Line: illustrative phishing volume index (base 100 = 2019). Both trends are directionally consistent with Verizon DBIR 2024 and APWG eCrime Reports 2019–2024 findings: authentication adoption has grown steadily while phishing volume has continued to climb—deployment gaps remain the primary attack surface.
Step-by-Step Implementation for Indian Businesses
Step 1 — Audit What You Currently Have
Run these checks before touching any DNS:
dig TXT yourdomain.in | grep spf
dig TXT _dmarc.yourdomain.in
dig TXT google._domainkey.yourdomain.inUse MXToolbox Email Health (https://mxtoolbox.com/emailhealth/) for a full audit. Note every external service that sends mail on your behalf: Google Workspace, Microsoft 365, Amazon SES, Mailchimp, Zoho Mail, bulk SMS gateways that send email receipts, CRM tools, invoicing SaaS.
Step 2 — Publish SPF
Add a single TXT record at your root domain. Include every legitimate sending source. End with -all. Wait for TTL propagation (typically 30–60 minutes for most Indian domain registrars on .in and .com zones).
Step 3 — Enable DKIM Signing
In each sending platform's admin console, generate a DKIM key pair and publish the public key as instructed. For Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate Email. For Microsoft 365: Security & Compliance Center → DKIM. For Amazon SES: SES console → Identities → DKIM.
Do not enable DKIM signing in the platform until after the DNS record has propagated.
Step 4 — Start DMARC at p=none
Publish your first DMARC record with p=none. This generates reports without affecting delivery. Run p=none for a minimum of two to four weeks—longer if you have many sending sources—and read your aggregate reports.
_dmarc.yourdomain.in TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.in; pct=100"Step 5 — Read Your DMARC Reports
Aggregate reports arrive as compressed XML files daily. Use a free parser like dmarcian (https://dmarcian.com) or dmarc.org's tools (https://dmarc.org/resources/tools/) to turn them into readable summaries. Look for:
- Sending sources you did not know about (shadow IT, forgotten marketing tools)
- Failures on sources you know should be passing
- Third-party forwarders that legitimately relay your mail
Step 6 — Harden to p=quarantine Then p=reject
Once your reports show that all legitimate mail passes, move to p=quarantine. Monitor for two weeks. If no complaints from internal users about missing mail, move to p=reject. This is the end state—at p=reject, spoofed messages from your domain are blocked at the receiver before the user ever sees them.
SPF, DKIM, DMARC — Comparison at a Glance
| Property | SPF | DKIM | DMARC |
|---|---|---|---|
| What it authenticates | Sending IP address | Message content and headers | Policy + alignment between SPF/DKIM and From domain |
| DNS record type | TXT at root domain | TXT at <selector>._domainkey.<domain> | TXT at _dmarc.<domain> |
| Survives email forwarding | No | Yes (usually) | Depends on alignment mode |
| Provides reporting | No | No | Yes — daily aggregate + per-message forensic |
| Can be enforced | Soft/hard fail | Pass/fail | p=none / quarantine / reject |
| Protects display From | No | Partially | Yes — with alignment |
Common Mistakes That Leave You Exposed
p=none forever. Organisations publish DMARC with p=none "to monitor" and then never graduate to enforcement. The policy does nothing to stop spoofing until you hit p=quarantine or p=reject. Set a calendar reminder for six weeks out.
Too many SPF lookups. Each include: in your SPF record costs one DNS lookup. Transitive includes count too. Exceeding ten causes permerror, which many receivers treat as SPF fail. Audit regularly as you add SaaS tools.
Missing subdomain policy. _dmarc.yourdomain.in only covers yourdomain.in by default. Attackers can spoof billing.yourdomain.in or noreply.yourdomain.in. Add sp=reject to your DMARC record to extend the policy to all subdomains, or publish separate DMARC records for each active sending subdomain.
Signing with a short key. 1024-bit DKIM keys can be factored by well-resourced attackers. Use 2048-bit minimum.
Not covering parked domains. If you own yourcompany-hr.in as a defensive registration but never send mail from it, publish a restrictive SPF (v=spf1 -all) and a reject DMARC (p=reject) to prevent abuse.
p=reject, your domain can still be spoofed. Start at p=none to collect data, graduate to p=reject within 60 days, and cover every parked subdomain.Where Bachao.AI and Dhisattva AI Pvt Ltd Fit In
Email authentication records live in DNS and are visible to any attacker who scans your domain. A free VAPT scan from Bachao.AI includes an automated check of your SPF, DKIM, and DMARC configuration—flagging missing records, soft-fail SPF, unenforced DMARC policies, and subdomain gaps—alongside the rest of your external attack surface. Dhisattva AI Pvt Ltd built the platform specifically so Indian SMBs can get this level of coverage without retaining a full-time security team.
For more coverage on email security, phishing defences, and compliance requirements under the DPDP Act, visit the Bachao.AI blog.
Frequently Asked Questions
Do I need all three — SPF, DKIM, and DMARC — or will just SPF do?
How long does DMARC implementation take for a small business?
p=none for two to four weeks while reading aggregate reports, then p=quarantine for another two weeks before moving to p=reject. Plan for six to eight weeks end-to-end if you have more than two or three sending services.What is BEC and why are Indian businesses targeted?
Can SPF break if I switch email providers?
What is DMARC alignment and why does it matter?
Does DMARC protect against phishing emails sent from lookalike domains?
sp= tag, your subdomains. A lookalike domain like yourcompany-in.com requires separate monitoring and takedown processes. DMARC is necessary but not sufficient—domain monitoring is a complementary control.