Email Authentication for Indian Businesses: SPF, DKIM and DMARC

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 -all

Breaking this down:

1. v=spf1 — declares this as an SPF record
2. include:_spf.google.com — authorises Google Workspace's sending IPs
3. include:amazonses.com — authorises Amazon SES if you send transactional mail through it
4. ip4:203.0.113.10 — authorises a specific on-premise mail relay
5. -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.

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.

DMARC — 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:

1. p=quarantine — send failing messages to spam; use p=reject once you are confident
2. rua= — aggregate report recipient; a daily XML digest of pass/fail counts per sending source
3. ruf= — forensic report recipient; per-message failure reports (not all receivers send these)
4. pct=100 — apply the policy to 100% of messages
5. adkim=s — strict DKIM alignment: the signing domain must exactly match your From domain
6. aspf=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:#e2e8f0

Email 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.in

Use 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:

1. Sending sources you did not know about (shadow IT, forgotten marketing tools)
2. Failures on sources you know should be passing
3. 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

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.

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.