← Back to blog

GUIDE

SPF, DKIM, and DMARC for Indian domains: a practical guide

By Paul Zacharia · 2026-08-04 · Updated 2026-09-30

If your transactional email is landing in spam, the first place to look isn't your content -- it's whether your domain is telling receiving mail servers you're allowed to send from it. Three DNS records do that job: SPF, DKIM, and DMARC. Get any one of them wrong and a receiving server has to guess whether a message claiming to be from your domain is real -- and increasingly, the big inbox providers guess "no."

SPF (Sender Policy Framework) is a TXT record listing which mail servers are allowed to send on behalf of your domain. Without it, any server can claim to send as yourdomain.in, and receivers have no way to tell your real transactional email apart from a spoofed one. SPF has a hard limit of 10 DNS lookups per check -- stack up enough third-party include: statements (your CRM, your helpdesk, your email API, a marketing tool) and you can silently exceed it, at which point SPF fails for everyone, including legitimate senders.

DKIM (DomainKeys Identified Mail) signs each outgoing email with a private key; the receiver checks the signature against a public key published in your DNS. This proves the message wasn't altered in transit and really came from a server you authorized. Unlike SPF, DKIM travels with the message itself, so it still validates correctly even when a message is forwarded through a server not listed in your SPF record.

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when SPF or DKIM checks fail -- quarantine, reject, or do nothing -- and where to send reports about failures. Without a DMARC policy, SPF and DKIM are advisory only; nothing enforces them, and you get no visibility into who is (or isn't) passing.

Why this matters more, not less, for Indian domains

Large inbox providers increasingly require all three records for any domain sending meaningful volume. Google's email sender guidelines apply to anyone sending close to 5,000 messages or more to personal Gmail accounts in a 24-hour period, and as of November 2025 Google has been actively enforcing rejections and delivery throttling for senders who don't meet them. Yahoo's Sender Hub requires bulk senders to authenticate with SPF and DKIM, publish a DMARC policy that actually passes, support one-click unsubscribe, and keep spam complaints under 0.3% -- with no minimum volume threshold published, so "we're too small for this to apply" isn't a safe assumption. A .in or .co.in domain gets no exemption from either.

Setting it up

MailKaka's domain setup walks through SPF, DKIM, and DMARC as one guided flow when you add a domain -- you don't hand-write the DNS records yourself. If you're setting this up manually with any provider:

  1. Add an SPF TXT record authorizing your sending provider's servers.
  2. Add the DKIM CNAME/TXT records your provider gives you after domain verification.
  3. Start DMARC at p=none (monitor-only) so you can see failure reports without blocking legitimate mail, then move to p=quarantine and eventually p=reject once you've confirmed nothing legitimate is failing.
  4. Re-check all three after any change to your sending setup -- adding a new provider without updating SPF is the most common cause of a domain silently failing authentication.

Common failure modes worth checking for

  • DNS propagation delay. A newly added record can take anywhere from a few minutes to 48 hours to propagate globally, depending on your DNS provider's TTL settings. Test before assuming a correctly-entered record is broken.
  • SPF alignment vs. DMARC alignment. DMARC checks that the domain in SPF or DKIM matches the visible "From" domain, not just that SPF or DKIM passed in isolation -- a message can pass SPF for a completely different sending domain and still fail DMARC.
  • Multiple SPF records. A domain can only have one SPF TXT record; adding a second one (common when a new tool tells you to "just add this SPF record" without checking for an existing one) makes SPF fail entirely rather than merging the two.

For a comparison of how MailKaka's guided setup differs from providers where deliverability reputation is the entire pitch, see MailKaka vs Postmark. Or jump straight to MailKaka's guided domain setup →

SPF, DKIM, and DMARC for Indian domains: a practical guide | MailKaka