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

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.

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.

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.

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.

Why this matters more, not less, for Indian domains

Large inbox providers (Gmail, Outlook, and India-specific corporate mail servers alike) increasingly require all three records for any domain sending meaningful volume -- Google and Yahoo's 2024 bulk-sender requirements made DMARC effectively mandatory for anyone sending 5,000+ emails/day to their users. A .in or .co.in domain gets no exemption from this.

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.

See MailKaka's guided domain setup →