Free SPF DKIM DMARC Record Generator

What is an SPF DKIM DMARC generator?

An SPF DKIM DMARC generator is a tool that writes the three DNS records used to authenticate your domain's email. You enter your domain, mail provider and policy, and it returns the record type, host and value you paste into your DNS panel.

Each record does a different job.

• SPF (Sender Policy Framework) is a TXT record listing the servers and services allowed to send email for your domain. Receivers compare the sending server against that list.
• DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing message. Receivers fetch a public key from your DNS and check the signature, which proves the message was not altered and came from a system you authorised.
• DMARC (Domain based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receivers what to do when a message fails both checks, and it sends you reports about who is using your domain.

Together they are the three email authentication standards. Without them, mailbox providers have little reason to trust mail that claims to come from you.

The SPF DKIM DMARC Record Generator on this page takes five inputs: your domain (the sample is example.in), your mail provider (Google Workspace, Microsoft 365, Zoho Mail India or other), an optional extra include from your sending tool's documentation, your DMARC policy (none, quarantine or reject) and a report email address (the sample is dmarc@example.in). It returns a table of DNS records, DKIM instructions for your provider, an SPF lookup counter for a record you paste, a three stage DMARC rollout plan and a verification checklist.

One important limit: the tool runs in your browser and cannot check live DNS. After you publish, verify the records with a DNS lookup tool and a test message. Confirm exact values in your provider's current documentation, since vendors update them.

Why does email authentication matter for Indian sales teams?

Authentication matters because it decides whether your emails reach the inbox, and Indian sales teams now depend on email for quotes, invoices, proposals and outreach. A missing record can quietly send your best messages to spam.

Here is what goes wrong without it:

• Quotes and invoices land in spam. A customer waiting for a GST invoice never sees it, and your team thinks they are being ignored.
• Cold outreach fails before it starts. A new sending domain with no authentication starts with a weak reputation. The Email Warmup Schedule Planner covers the ramp that follows.
• Anyone can pretend to be you. Without DMARC, a fraudster can send an email that looks like it comes from your domain, asking a customer to pay into another account.
• Bulk sender rules apply. Google and Yahoo introduced bulk sender requirements in 2024, covering authentication, easy unsubscribe and low spam complaint rates. Requirements change, so verify the current rules for your volume.
• Reports show hidden senders. DMARC reports reveal forgotten tools sending as your domain.

Indian teams often have many systems sending as one domain: Google Workspace or Microsoft 365 for staff, a bulk tool such as Zoho Campaigns or Mailchimp, an outreach tool, a billing system and a CRM or support desk. Each needs to be in SPF and, ideally, sign with DKIM.

The DPDP Act expects reasonable safeguards for personal data, and spoofing is part of that risk. This is general guidance, not legal advice.

Do authentication first, then warm up, then send sequences from the Cold Email Sequence Generator, and check your copy with the Cold Email Spam Checker. Records alone do not make a bad email good, but a good email without them often never arrives.

How to use the SPF DKIM DMARC Record Generator

You use the generator by entering five values, copying the records it produces into your DNS panel, completing the DKIM step in your provider's console, and then verifying everything.

1. Enter your domain. Use the exact domain you send from, such as example.in.
2. Choose your mail provider. Pick Google Workspace, Microsoft 365, Zoho Mail India or other. This decides the SPF include value and the DKIM instructions.
3. Add an extra include if needed. If you send from a bulk or outreach tool, copy the include value from that tool's documentation. Do not guess it.
4. Pick a DMARC policy and a report address. Start with none. Use a mailbox someone monitors, since reports arrive as XML files.
5. Copy the records into DNS. In your domain registrar or DNS host, add each record using the type, host and value in the table. Edit an existing SPF record instead of adding a second one.
6. Create the DKIM key in your provider console. The generator cannot create keys. Generate it in your provider's admin console, then publish the TXT or CNAME record it gives you.
7. Verify. Wait for DNS to update, then check each record with a lookup tool, send a test email to an external mailbox and inspect the headers for pass results.

What to do with the result: publish the SPF record only once, keep a copy of the values, and review DMARC reports weekly. Paste your existing SPF record into the lookup counter first to see whether another include will push you past the limit.

How are SPF, DKIM and DMARC records built?

Each record follows a fixed format, and the generator assembles it from your inputs. Knowing the format lets you check the output yourself and fix mistakes.

SPF is a single TXT record at the root of your domain, shown as the host @. Its general form is:

v=spf1 include:<provider include> [include:<extra include>] ~all

Provider values the generator uses are:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Zoho Mail India: include:zoho.in

The ending decides how failures are treated. A tilde before "all" means soft fail, which marks unauthorised senders as suspicious. A minus before "all" means hard fail. You can only have one SPF record per domain. Two records cause SPF to fail.

The 10 lookup limit. SPF allows a maximum of 10 DNS lookups while evaluating a record. Mechanisms such as include, a, mx, ptr, exists and the redirect modifier each count, and an include also counts the lookups inside the included record. The ip4 and ip6 mechanisms do not count. If you exceed 10, SPF returns a permanent error and fails. The generator includes a counter that scans a record you paste and counts these terms. It cannot see inside included records, so a count that looks safe may still be higher in practice. Test with a full SPF checker too.

DKIM uses a public key published at a host with this pattern:

selector._domainkey.example.in

The selector is a name chosen by your provider or you. Google Workspace commonly uses a TXT record, Microsoft 365 uses CNAME records that point to Microsoft hosted keys, and Zoho gives you a TXT record. The actual key value comes from your provider.

DMARC is a TXT record at the host _dmarc. Its default output is:

v=DMARC1; p=none; rua=mailto:dmarc@example.in; fo=1

Tags explained:

• v is the version and must be DMARC1.
• p is the policy: none (monitor only), quarantine (treat as suspicious, usually spam folder) or reject (refuse the message).
• rua is where aggregate reports are sent.
• fo=1 asks for failure reports when any check fails, where supported.
• pct (optional) applies the policy to a percentage of failing messages, used during rollout.

DMARC passes when SPF or DKIM passes and the passing domain aligns with the visible From domain. A tool that sends from its own domain can pass SPF yet still fail DMARC.

Worked example: authenticating example.in on Google Workspace

This example uses the generator's sample inputs: domain example.in, mail provider Google Workspace, no extra include, DMARC policy none and report email dmarc@example.in. The output is shown as the tool displays it, and it is illustrative. Your values must come from your own provider.

For DKIM, the Google Admin console shows the exact host name and a long public key value after you generate it. Use those exact values. Do not type a key from memory or from this page.

Now suppose the same company also uses an outreach tool and adds an extra include. The tool's documentation gives a value, so the SPF line might read:

v=spf1 include:_spf.google.com include:mail.outreachtool.example ~all

The lookup counter would show 2 lookups from the visible terms. Google's own include contains more lookups inside it, so the true total is higher, and several tools can approach 10 faster than expected.

How to read the example:

• SPF says only Google's mail servers may send as example.in. Anything else is soft failed.
• DKIM adds a signature that Gmail and other receivers can verify.
• DMARC with p=none takes no action on failing mail. It simply asks receivers to send reports to dmarc@example.in, so you can see who sends as your domain.

Then follow the rollout: stay on none for a few weeks while you fix failing legitimate senders, move to quarantine with a small pct value and raise it gradually, and only then consider reject.

How do you read your result?

You read the result by checking that each record exists exactly once, that the SPF record stays under 10 lookups, that DKIM signs your mail, and that DMARC reports arrive. A pass on all three is the goal, but the stage you are at matters.

Your DMARC policy tells you where you are in the journey:

• none: monitoring. You are collecting information. Spoofed mail is still delivered.
• quarantine: failing mail is treated as suspicious. Move here only after reports look clean.
• reject: failing mail is refused. This gives the strongest protection and the highest risk if a legitimate sender was missed.

To check a test message, open the original message headers in Gmail or Outlook and look for results labelled spf, dkim and dmarc. You want pass for all three. If SPF fails, check that the sending service is in the record. If DKIM fails, check that signing is on and the key is published. If DMARC fails while the others pass, suspect alignment.

Reports are XML summaries from large receivers listing sending IP addresses, counts and results. Many teams use a report viewing service to read them; check each vendor's current plans and limits. Look for unfamiliar senders and decide whether each is a forgotten tool or a misuse.

Email authentication setup by industry

The records are the same for every domain, but the senders you must account for differ by sector.

Real estate

Property teams send from many places: brokers on personal addresses, a portal lead notification, a marketing tool for brochures and a CRM. List every system before moving beyond p=none. Fake booking and payment emails are a real risk, so aim for quarantine or reject once reports are clean.

Education (schools, colleges, EdTech, study abroad)

Institutions often run several domains, such as a school domain, a fee portal and an admissions microsite. Authenticate each one. Fee reminders and admit cards sent by an ERP or LMS often come from a third party, so add its include and DKIM. A strong DMARC policy protects parents from fake admission emails.

Manufacturing and B2B

Purchase orders, quotations and dispatch notices travel by email, and vendors may send on your behalf through ERP systems. Inventory these senders first. Spoofed invoices can redirect payments, so move toward quarantine once your own systems pass.

Healthcare and clinics

Appointment reminders, reports and billing may come from a hospital system, a lab portal or a third party. Make sure each signs with DKIM. Keep patient data out of report mailboxes. Aim for enforcement, but test carefully, since missing a lab sender can block reports.

Automotive

Dealerships often send from a dealer management system, an OEM portal and local marketing tools, so authentication can get messy. Ask each vendor for its recommended SPF and DKIM setup. A blocked service reminder costs revenue, so start with none and move in small steps.

Insurance and financial services

Policy documents, premium reminders and renewal notices must arrive and must be trusted. Customers are common phishing targets, so enforcement matters. Use DKIM for every sender, keep SPF tidy and record every change for audits.

SMBs and services

A small business usually has one mailbox provider, an invoicing tool and maybe a newsletter tool. Publish SPF, DKIM and DMARC with p=none today, read reports for a month, then tighten. Set a calendar reminder, since small teams often leave DMARC at none forever.

What mistakes do teams make with SPF, DKIM and DMARC?

The usual mistakes are duplicate records, too many lookups, skipping DKIM and jumping to reject. Each is easy to avoid with a short checklist.

• Publishing two SPF records. Only one SPF record is allowed per domain. Merge all includes into a single line.
• Passing 10 lookups. Adding every tool's include pushes SPF into a permanent error. Remove old vendors and consider consolidating senders.
• Ending with +all. This allows anyone to send as your domain and defeats the purpose.
• Forgetting third party senders. Newsletter, billing and support tools send as your domain too. Find them in DMARC reports.
• Skipping DKIM. SPF breaks when mail is forwarded. DKIM often survives forwarding and helps DMARC pass.
• Setting reject too early. You may block your own email. Move up in stages.
• Pointing reports to an unread inbox. Reports are only useful if someone reviews them.

How can you improve your email authentication?

You improve authentication by taking an inventory of senders, publishing records, monitoring reports and tightening policy in stages. Treat it as a short project with an owner and dates, not a one time chore.

Week 0: inventory and plan (owner: IT or operations head)

• List every system that sends email as your domain.
• Find who controls DNS and save a copy of all current records.

Week 1: publish and verify (owner: DNS administrator)

• Publish SPF, then enable DKIM in the provider console, then publish DMARC with p=none.
• Use the lookup counter to keep SPF under 10.

Weeks 2 to 4: monitor and fix (owner: IT with sales and marketing)

• Read reports weekly and list each sending source with its status.
• Add DKIM and SPF for legitimate sources that fail.

Weeks 5 to 8: tighten (owner: head of IT or founder)

• Move to quarantine with a low pct, such as 10, then raise it step by step.
• Move to reject only when reports have been clean for some time.

Ongoing

Plan inboxes and domains using the Sending Inbox Capacity Calculator, and keep outreach on a separate domain from your main one.

Verification checklist:

• One SPF record only
• SPF under 10 lookups
• DKIM published and test mail signed
• DMARC record at _dmarc
• Reports arriving
• Test message passes in headers

SPF DKIM DMARC setup: spreadsheet, CRM or Erino?

A spreadsheet can track your records, your mail provider and DNS host do the real work, and a CRM handles leads after email arrives. Erino is a CRM and does not manage DNS or authenticate your domain.

Authentication is configured in DNS and in your mail or sending tools, and a CRM does not replace it. Erino does not send cold email sequences, warm up inboxes, scrape LinkedIn or find leads. Erino starts when a lead or reply arrives, and good authentication helps those replies reach you in the first place.

Once your domain is authenticated, your outbound tools can send, and replies can flow into your CRM. If your lead sources include website forms, Meta lead ads and portals, Erino's 100+ integrations bring them into one place with an owner and a follow up on each. Read more on the Erino platform, compare options on the Zoho CRM alternatives page or see the pricing page, where pricing is quoted after a free 15 minute demo. Erino hosts data in India. A fast first reply also depends on seeing the message, so see the Lead Response Time Calculator.

Frequently asked questions

Written by the Erino team

Erino Tech Ventures Pvt. Ltd. builds Erino, an AI first sales CRM for high velocity sales teams in India. Last reviewed 26 Oct 2026. This tool runs in your browser; the numbers you type are not sent anywhere.

Customer results mentioned here come from Erino's published success stories.