Business Email on Your Domain: SPF, DKIM & DMARC Setup for Indian Small Businesses

1. The quick answer: which DNS records do you need?

You usually need four separate pieces of configuration. MX records tell other mail servers where to deliver incoming email. SPF identifies which sending systems are authorised for a domain. DKIM lets a sending system sign outgoing messages so a recipient can verify the signature using a public key published in DNS. DMARC tells receiving systems how to evaluate messages that claim to come from your domain and where to send aggregate reports.

These records solve different problems. Adding an MX record does not authenticate outgoing mail. Publishing SPF does not create mailboxes. A DMARC record cannot repair a sender that has not been configured to authenticate and align correctly. Your email provider supplies the exact values for its service; do not copy another company's DNS values.

• MX — where incoming email for the domain should be delivered.
• SPF — which servers or services may send using the relevant envelope-sender domain.
• DKIM — a cryptographic signature on outgoing mail, verified using a public key or provider-controlled selector in DNS.
• DMARC — a policy and reporting mechanism that checks whether SPF or DKIM authentication aligns with the visible From domain.

2. Understand the three providers involved

A domain registrar is where the domain registration is maintained. A DNS host is the service that answers for the domain's active nameservers and stores records such as A, CNAME, MX and TXT. An email host or mailbox provider stores mailboxes and sends or receives messages. These can be three different companies.

If your nameservers point to Cloudflare, add the email DNS records in the Cloudflare DNS zone even if you purchased the domain from a different registrar. If the nameservers point elsewhere, edit the active DNS host instead. Cloudflare's documentation describes how to add and edit records in its DNS dashboard. Changing records at the wrong provider will not change the live DNS zone.

Keep website and email records separate in your change plan. A website's A or CNAME record controls web traffic; MX records control incoming mail; SPF, DKIM and DMARC are usually TXT records or, for some providers, DKIM CNAME records. Do not replace website A/CNAME records while trying to set up email.

• Check the domain's current nameservers before making a change.
• Export or record the existing DNS zone before editing it.
• Use the DNS values shown in your email provider's current admin console.
• Do not delete old MX records until a planned mailbox migration and mail-flow test are complete.

3. SPF, DKIM and DMARC in plain English

SPF (Sender Policy Framework) is checked against the domain used by the SMTP envelope sender, often visible as the Return-Path or bounce address. It is not simply a list of the visible From addresses. If a website, CRM or newsletter platform sends mail for your domain, that service must be included in the relevant SPF design or use a separately authenticated sending subdomain.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to an outgoing message. The sender keeps the private signing key; the matching public key is published in DNS. A selector in the DKIM-Signature header tells the recipient which DNS key to look up. Google Workspace commonly asks administrators to publish a TXT key, while Microsoft 365 custom-domain setup uses provider-generated CNAME selectors. Follow the record type and values generated for your tenant.

DMARC (Domain-based Message Authentication, Reporting and Conformance) connects those authentication results to the domain in the visible From header. A DMARC pass requires at least one of SPF or DKIM to pass and the corresponding authenticated domain to be aligned with the From domain. A message can show SPF=pass and DKIM=pass but still fail DMARC if neither authenticated domain aligns.

A DMARC pass confirms an authorised relationship with the sending domain; it does not guarantee inbox placement. Recipient filtering, sender reputation, message quality, complaint rates and list hygiene still matter. The current DMARC core specification is IETF RFC 9989 (May 2026); RFC 9990 covers aggregate reporting.

4. Why small businesses should inventory every sender first

The most common setup gap is authenticating the mailbox provider but forgetting another service that sends as the same domain. A founder may send normal messages through Gmail or Outlook, while the website sends contact-form notifications through a transactional provider, invoices come from an accounting platform, and marketing emails come from a separate campaign tool. Those are different sending sources.

Create a sender inventory before changing SPF or DMARC. For each system, record the service owner, sending domain, visible From address, Return-Path or envelope domain, DKIM signing domain (the d= value), whether it sends directly or through another provider, and whether the service is still in use. Ask each provider for its current SPF, DKIM and custom-domain instructions.

Include devices and less obvious systems: scanners, printers, CRM workflows, booking tools, payment notifications, help desks, password-reset messages, recruitment systems and website hosting. If a system cannot authenticate mail with your domain, do not assume that adding a random IP to SPF is the correct fix; ask the provider for its supported custom-domain method.

• Mailbox provider: Google Workspace, Microsoft 365, Zoho Mail or another host.
• Website and application mail: contact forms, password resets, receipts and system alerts.
• Business tools: CRM, accounting, invoicing, ERP, ticketing and appointment platforms.
• Marketing: newsletter, campaign and bulk-email services.
• Operational senders: scanners, printers, booking tools and outsourced support systems.
• Retired services: remove old authorisations only after confirming that no live workflow still depends on them.

5. Choose a mailbox provider separately from DNS authentication

SPF, DKIM and DMARC are standards that work across providers. Choosing Google Workspace, Microsoft 365 or Zoho Mail does not remove the need to understand your sending sources. Compare mailbox features, administration, migration, storage, support, user controls and total subscription cost; then use the provider's own admin console to generate the exact DNS records.

Google Workspace positions Business Starter as a custom-domain Gmail and collaboration suite. Its India pricing page, checked on 12 November 2026, displayed ₹160.65 per user per month with an annual commitment and ₹193.38 for flexible billing; promotional terms and final checkout may change the payable amount.

Microsoft 365 Business Basic (no Teams) was listed at ₹130 per user per month on annual billing, with GST extra. It includes custom business email through Exchange and web/mobile productivity apps. Microsoft 365 DKIM uses two provider-generated CNAME selectors for a custom domain; do not substitute a generic TXT example.

Zoho Mail offers mailbox-focused plans with 5 GB or 10 GB Mail Lite storage per user on annual subscriptions. Its free custom-domain plan is available only in selected data centres, so confirm regional availability before designing a business around it. Zoho's Admin Console provides SPF, DKIM and DMARC verification steps.

These are examples of provider models, not a recommendation that one provider is best for every organisation. A business with only a few mailboxes may prioritise cost and administration; a team that also needs shared files, calendars, identity controls and office applications may compare full productivity suites. Email subscriptions, DNS configuration, migration and third-party sending fees are separate cost lines.

• Google Workspace — Gmail and collaboration suite with custom-domain email.
• Microsoft 365 — Outlook/Exchange email combined with web/mobile Office and cloud services.
• Zoho Mail — mailbox-centric business email with a domain administration console.
• Specialist email host or reseller — may bundle setup, migration and support; verify the actual mailbox provider, data location, backup, support and renewal terms.

6. Configure DNS in a safe order

Step 1 — Verify domain ownership. Add the TXT or CNAME verification value generated by the email provider. Verification proves control of the domain; it does not automatically route mail or authenticate every sending service.

Step 2 — Configure MX records for incoming mail. Copy the exact MX hostnames and priorities from the provider's current setup screen. If you are migrating from an existing mailbox host, plan the cutover, mailbox migration and old-provider retention first. Do not remove existing MX records simply because a new provider has supplied different values.

Step 3 — Build the SPF record. Publish one SPF TXT record for each domain or subdomain that sends mail. If Google Workspace is the only sender, Google currently documents `v=spf1 include:_spf.google.com ~all` as its example. Microsoft 365 and Zoho publish different provider-specific values. If several services send as the same domain, combine the authorised mechanisms into one SPF record; do not create one separate SPF record per service.

SPF evaluation has a limit of ten DNS-query-causing terms such as include, a, mx, ptr, exists and redirect. Exceeding the limit can produce a permanent SPF error. Avoid adding every vendor you have ever tested, avoid permissive `+all`, and do not copy an SPF record from a different domain or tenant.

Step 4 — Enable DKIM for every legitimate sending platform that supports it. Generate the selector and key or CNAME values inside that provider's administrator console, add the DNS record exactly as shown, wait for the provider to detect it, and then switch DKIM signing on. Keep the private key inside the sending system; only the public key or provider-directed CNAME belongs in DNS.

Step 5 — Add DMARC after SPF and DKIM are working. Google recommends setting up SPF and/or DKIM first and allowing at least 48 hours before configuring DMARC. A cautious starting record is `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.in` — replace the example address with a real mailbox or group you control. The `p=none` policy is for monitoring; it does not quarantine or reject failing mail.

• Use the provider-generated MX, SPF and DKIM values rather than generic internet examples.
• Keep one SPF record per sending domain or subdomain.
• Keep separate subdomains' sender inventories and SPF records separate.
• For Microsoft 365 DKIM CNAMEs in Cloudflare, Microsoft instructs administrators to set the records to DNS only, not proxied.
• Do not publish `p=quarantine` or `p=reject` until every legitimate sender has been identified and tested.

7. The DMARC alignment problem that catches third-party senders

Imagine your customer sees `From: invoices@yourbusiness.in`, but the invoicing platform sends through `bounce.vendor-mail.example` and signs the message with `d=vendor-mail.example`. SPF may pass for the vendor's envelope domain and DKIM may pass for the vendor's signing domain. If neither authenticated domain aligns with `yourbusiness.in`, DMARC can still fail.

Ask the third-party provider whether it supports a custom Return-Path or custom DKIM signing domain. Configure the service to authenticate with a domain or subdomain that aligns with the visible From domain under the alignment mode you use. Test the actual received message headers; a dashboard that says a domain is verified does not prove that every template or sending stream is aligned.

Forwarding can also affect authentication. SPF may fail when a forwarder changes the sending path, while DKIM may continue to pass if the signed content is not altered. This is one reason DMARC can pass through aligned DKIM even when SPF fails. Do not change to strict alignment or a reject policy without understanding the actual mail flow.

8. Test every sending source before tightening the policy

Send a test message from each legitimate source to at least one Gmail mailbox and one non-Gmail mailbox you control. In Gmail, open the message and use Show original to inspect Authentication-Results and the visible From address. Check the corresponding headers in Outlook or the recipient provider's message details.

For each source, record whether SPF passed, DKIM passed, and DMARC passed. Then check alignment: which domain passed SPF, which domain appears in the DKIM d= value, and whether at least one aligns with the From domain. Test website contact-form notifications, invoices, password resets, CRM messages and marketing mail separately; one successful mailbox test does not validate all systems.

Google's sender guidelines require SPF or DKIM for all senders to personal Gmail accounts. Senders sending more than 5,000 messages per day to Gmail accounts must use SPF, DKIM and DMARC, align the From domain with SPF or DKIM, and meet additional requirements such as one-click unsubscribe for marketing and subscribed messages. These are Gmail platform requirements, not a general Indian statutory licence or a guarantee of delivery.

Use DMARC aggregate reports to identify sending IPs, authentication results and sources that claim to use your domain. RFC 9990 (May 2026) specifies DMARC aggregate reporting. Treat unfamiliar sources as an investigation item, not automatic proof of malicious activity; some may be legitimate third-party services or forwarding paths.

• Test normal person-to-person mail from each mailbox provider.
• Test every website or application that sends a message using your domain.
• Test each third-party CRM, billing, support and campaign platform.
• Check SPF and DKIM pass results and DMARC alignment, not only the presence of DNS records.
• Keep a dated record of test sender, recipient, message ID, authentication results and any correction made.

9. Move from monitoring to enforcement gradually

Keep `p=none` while you review aggregate reports and confirm which sources are legitimate. Correct missing SPF mechanisms, enable DKIM signing, fix custom Return-Path or DKIM alignment, and retire senders that are genuinely no longer used. A monitoring policy provides visibility but does not ask recipients to quarantine or reject failing messages.

When the legitimate sources are consistently aligned, move to `p=quarantine` and monitor for unexpected failures. Only move to `p=reject` when the organisation has evidence that its legitimate mail streams pass and the business can respond quickly if a new service is introduced. The change should be controlled by whoever owns email operations, not copied from a competitor's DNS record.

Aggregate reports are usually XML and can be difficult to read manually. Use a controlled mailbox or a reporting tool with a clear data-handling policy. RFC 9991 describes DMARC failure reports; such reports can contain message headers and sometimes message content, which may include personal information. Do not request or forward detailed failure reports without considering privacy and access controls.

• Start with monitoring (`p=none`) and review the reports.
• Fix every known legitimate sender before enforcement.
• Move to quarantine only after testing and monitoring.
• Move to reject only after the organisation is confident that legitimate streams are aligned.
• Repeat the inventory and tests whenever a new CRM, website sender or marketing platform is introduced.

10. Common mistakes and how to avoid them

• Publishing two SPF records: merge authorised sources into one SPF record for that domain or subdomain.
• Adding only the mailbox provider: include website forms, CRMs, billing tools and marketing platforms that send as your domain.
• Exceeding the SPF lookup limit: review nested includes and remove obsolete sources; do not blindly add more includes.
• Copying DKIM values from a tutorial: use the selector and key/CNAME values generated for your own provider tenant.
• Publishing DMARC reject immediately: monitor first and prove that legitimate mail is aligned.
• Editing DNS at the registrar when another provider hosts the active nameservers: make changes in the authoritative DNS zone.
• Changing MX without a migration plan: old mail can stop arriving or new mail can be split between providers.
• Proxying a provider-specific DKIM CNAME: follow the email provider's DNS-only instruction where required.
• Assuming a DMARC pass guarantees inbox placement: authentication is one signal; content, reputation, complaints and recipient rules still matter.

11. A practical seven-day implementation checklist

• Day 1 — Record the domain's nameservers and export the DNS zone. List every mailbox and every system that sends mail using the domain.
• Day 2 — Choose the mailbox provider and verify domain ownership. Confirm mailbox users, aliases, migration needs, administrator access and renewal costs.
• Day 3 — Configure MX records using the provider's exact values. Test inbound and outbound mail before removing any old service.
• Day 4 — Build one SPF record from the complete sender inventory. Check for duplicate records and the ten DNS lookup limit.
• Day 5 — Generate and publish each provider's DKIM selector. Verify the record in the provider console and send test messages.
• Day 6 — Add DMARC with a real aggregate-report destination and `p=none`. Do not enforce quarantine or reject yet.
• Day 7 — Review message headers and reports, correct alignment issues, document the results and assign an owner for future DNS changes.

Frequently asked questions

Do I need MX, SPF, DKIM and DMARC? MX is needed to route incoming mail to your mailbox provider. SPF and DKIM authenticate outgoing mail, and DMARC adds alignment, policy and reporting. The exact records depend on the provider and the systems that send mail for your domain.

Does buying a domain automatically give me business email? No. Domain registration and mailbox hosting are separate services. You need an email provider or hosting plan that creates and manages the mailboxes.

Can I have more than one SPF record? No. Publish one SPF record for each domain or subdomain that sends mail. If multiple services send from the same domain, combine their authorised sources in that one record. Multiple SPF records can cause SPF evaluation errors.

Does SPF authenticate the visible From address? SPF evaluates the SMTP envelope-sender domain (or HELO identity in specified cases). DMARC checks whether the SPF-authenticated domain aligns with the visible From domain.

Why does DMARC fail when SPF and DKIM both pass? The authenticated SPF domain and DKIM signing domain may not align with the visible From domain. Check the Return-Path, DKIM d= value and DMARC alignment result.

Should I start DMARC with p=reject? Not if you have not inventoried and tested every legitimate sender. Start with monitoring, fix legitimate sources, then move to quarantine and reject when the evidence supports it.

Will SPF, DKIM and DMARC guarantee that emails reach the inbox? No. They help receiving providers authenticate the sending domain, but inbox placement also depends on reputation, message content, complaint rates, recipient engagement and provider filtering.

Can my website send mail from my domain? Yes, if the website's sending provider supports a properly authenticated and aligned custom domain. Ask for its SPF and DKIM instructions, test the actual message headers, and include it in the sender inventory.

Can I use a separate subdomain for newsletters or automated notifications? Yes, many organisations separate marketing or transactional streams on a subdomain. Configure its own sending records and DMARC behaviour, and make sure the visible From domain aligns with the authenticated sender. A subdomain is not automatically configured just because the parent domain is.

Does Cloudflare provide a business mailbox? Cloudflare DNS can host the records needed to connect a domain to an email provider, but DNS hosting is not the same as buying a mailbox subscription. Confirm the email-hosting product separately.

12. How FIN.SWITCH can help

If your business is building or refreshing its website and needs the domain, website forms and business-email flow planned together, FIN.SWITCH can help scope the website and technical requirements. The published GROW Website service covers a multi-page business website, lead forms, SEO structure, analytics-ready setup and blog architecture. Mailbox subscriptions, email migration, DNS authentication work and third-party sending charges are separate items unless they are explicitly included in an agreed scope.

FIN.SWITCH is not an email provider, registrar, DNS authority or mail-delivery guarantee service. For changes to an existing production mail system, the current email administrator or provider should approve the record values and migration plan. If you need help documenting the requirements or coordinating a website-related setup, use the contact page to describe your domain, mailbox provider and sending systems.

• Explore the FIN.SWITCH GROW Website service for a scoped website and lead-capture build.
• Review the DPDP website-readiness guide if your enquiry forms collect personal data.
• Contact FIN.SWITCH for a discussion of the website, domain and email requirements before any DNS changes are made.