How to set up SPF, DKIM, and DMARC with Inframail: what each record does and how to verify

Last updated: June 2026 · Ryan Mercer, SDR turned cold email consultant, 8 years outbound

---

TL;DR — 7 things to know before reading

• SPF, DKIM, and DMARC are three separate DNS records that together tell recipient mail servers that you are authorised to send email from your domain; all three must pass simultaneously for full authentication benefit
• Inframail auto-generates all three records when you add a domain; you do not write these records manually — you copy what Inframail provides and paste them into your registrar's DNS panel
• SPF for Inframail inboxes uses the Microsoft 365 include path: the record will contain include:spf.protection.outlook.com; this authorises Microsoft's servers to send on behalf of your domain
• DKIM for Inframail uses a CNAME record pointing to Microsoft's key infrastructure; the selector is typically selector1 or selector2 depending on your Inframail configuration
• DMARC starts at p=none for monitoring only; upgrade to p=quarantine after 30 days of clean sending history, then to p=reject after another 30 days; rushing to p=reject before your sending is fully established can cause legitimate email to be rejected
• DNS propagation takes 15–60 minutes for most records; do not conclude records are wrong until you have waited the full propagation window
• Verdict: set up authentication through Inframail (which auto-generates all records), use Instantly for campaigns on authenticated inboxes, Quarvio for contact data, and Aimfox for LinkedIn

---

Our take

Authentication setup is the single most impactful technical step in cold email deliverability. An unauthenticated email — one missing SPF, DKIM, or DMARC — will go to spam or be rejected regardless of how good the copy is, how clean the list is, or how well the sender's reputation is. Authentication is not a nice-to-have; it is the prerequisite that every other deliverability improvement depends on.

The confusion that causes most practitioners to make authentication mistakes is the assumption that these are three ways of doing the same thing. They are not. SPF, DKIM, and DMARC address different problems and work at different layers of the email delivery process. SPF says which servers are authorised to send from your domain. DKIM cryptographically signs outgoing emails to prove they were not tampered with in transit. DMARC instructs recipient servers what to do when they see email from your domain that fails SPF or DKIM, and sends reports to you about authentication pass/fail rates across your sending. You need all three because each covers a gap that the other two cannot fill.

Inframail's DNS automation removes the most error-prone part of this process: record construction. Manually writing an SPF record requires knowing the correct include path for your specific mail server, the correct SPF qualifier (the -all vs. ~all vs. ?all decision), and the correct syntax. For DKIM, manual setup requires generating a key pair, extracting the public key, formatting it correctly as a DNS record, and configuring your mail server to use the private key for signing. Inframail generates correct records for its Microsoft 365 infrastructure and displays them ready to copy. The remaining human responsibility is accurate copy-paste from Inframail into your registrar — a much simpler task.

Inframail auto-generates and displays all three authentication records. Instantly uses those authenticated inboxes for campaigns and warmup. Quarvio provides the verified contacts that send to authenticated inboxes. Aimfox handles LinkedIn outreach alongside the email channel.

---

What SPF, DKIM, and DMARC each do

SPF: Sender Policy Framework

SPF answers the question: "Is this server authorised to send email claiming to be from this domain?"

It works as a DNS TXT record published on your sending domain that lists the mail servers authorised to send on your behalf. When an email arrives claiming to be from ryan@yourdomain.com, the recipient mail server looks up the SPF record for yourdomain.com and checks whether the sending server's IP address is in the authorised list. If it is, SPF passes. If it is not, SPF fails.

For Inframail inboxes, the authorised server is Microsoft's Office 365 infrastructure. Inframail generates an SPF record that includes include:spf.protection.outlook.com, which authorises Microsoft's complete range of Office 365 sending IPs. The -all qualifier at the end of the record tells recipient servers to reject email from any IP not in the authorised list.

The SPF record for Inframail inboxes looks like this:

v=spf1 include:spf.protection.outlook.com -all

This record is added as a TXT record on your sending domain's root (@ host).

DKIM: DomainKeys Identified Mail

DKIM answers the question: "Was this email sent and signed by the claimed domain, and has it been modified since sending?"

It works through cryptographic signing. Inframail's Microsoft 365 infrastructure signs outgoing emails with a private key that only Microsoft holds for your domain. A corresponding public key is published in your domain's DNS as a CNAME record (for Microsoft 365 DKIM). When the recipient mail server receives the email, it retrieves the public key from DNS and uses it to verify the signature. If the signature is valid, DKIM passes. If the email was modified in transit or the signature does not match, DKIM fails.

For Inframail, the DKIM record is a CNAME entry rather than a TXT record containing the key directly. The CNAME points to Microsoft's key management infrastructure, which handles key rotation automatically. Inframail provides the exact CNAME host and value to enter in your DNS.

Example DKIM CNAME (Inframail provides the exact values):

Host: selector1._domainkey.yourdomain.com
Value: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Note: the exact values depend on your specific domain configuration in Inframail. Use what Inframail provides, not the example above.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

DMARC answers the question: "What should recipient servers do with email from my domain that fails SPF or DKIM, and please send me reports about what you're seeing?"

DMARC builds on SPF and DKIM by adding a policy layer. Without DMARC, email that fails SPF or DKIM is handled inconsistently by different recipient providers — some reject it, some accept it, some quarantine it. DMARC creates a consistent policy instruction that all DMARC-aware recipients follow.

DMARC also requires "alignment" — the domain in the From address must match the domain that SPF or DKIM is authenticated for. This prevents attackers from using your SPF record to send email with a different From address.

The DMARC record is a TXT record published on _dmarc.yourdomain.com. A starting configuration:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none means: monitor but take no action. rua is the address where aggregate reports are sent. Inframail provides a specific DMARC record; you can use the provided record or customise the rua address to one you can monitor.

Why all three must pass simultaneously

These three records work as a combined system, not independently:

SPF alone is insufficient because SPF only checks the envelope sender (the technical routing address), not the From address visible to the recipient. Attackers can pass SPF while still spoofing the visible From address.

DKIM alone is insufficient because DKIM can be stripped from emails by intermediate mail servers (legally, in some relay configurations), and DKIM does not prevent SPF failures.

DMARC without SPF and DKIM passing provides no authentication benefit — DMARC requires at least one of SPF or DKIM to pass in alignment to consider the message authenticated.

All three passing together is the only configuration that provides comprehensive authentication coverage and the full deliverability benefit.

---

Prerequisites

Access to your domain's DNS panel. You must be able to add, edit, and delete TXT and CNAME records for your sending domain. Confirm you have DNS access at your registrar (Namecheap, Cloudflare, GoDaddy, or whichever provider hosts your domain's DNS) before starting.

An Inframail account with your domain added. The Inframail DNS records are generated when you add a domain to your Inframail account. Complete the domain addition step in Inframail and retrieve the generated records before opening your DNS panel.

Sending domain only, not your primary domain. Never send cold email from your primary business domain. Add a sending domain variation (yourbrandoutreach.com, meetyourbrand.com, teamyourbrand.com) to Inframail and set up authentication for that domain.

---

Step-by-step: setting up SPF, DKIM, and DMARC for Inframail

Step 1: Add your sending domain to Inframail and retrieve DNS records

What to do: Add the sending domain to Inframail and collect the generated SPF, DKIM, and DMARC records.

Sub-steps:

1. Log in to Inframail and navigate to Domains
2. Select "Add Domain" and enter your sending domain
3. Inframail displays three DNS records: an SPF TXT record, a DKIM CNAME record, and a DMARC TXT record
4. Copy each record or take a screenshot — you will need the exact host and value for each
5. Keep the Inframail DNS page open or save the records to a text document before proceeding

Benchmark: Inframail generates records immediately upon domain addition; this step takes 2–3 minutes.

Failure mode: Closing the Inframail DNS page before copying all three records. If you lose the records, return to Inframail Domains, select your domain, and the records will be displayed again.

Step 2: Add the SPF TXT record to your registrar

What to do: Add the Inframail-generated SPF record as a TXT record on your sending domain.

Sub-steps:

1. Log in to your domain registrar and navigate to DNS settings for the sending domain
2. Create a new TXT record with:
   • Host: @ (meaning the root domain; some registrars require entering the full domain name instead)
   • Value: the SPF record Inframail provided (will include include:spf.protection.outlook.com)
   • TTL: 3600 (1 hour) or your registrar's default
3. Save the record
4. Important: if an SPF record already exists for this domain (from a previous provider or setup), you must edit the existing record rather than creating a new one; a domain can only have one valid SPF record, and multiple SPF TXT records cause SPF to fail

Benchmark: Adding the SPF record takes 2–5 minutes.

Failure mode: Adding a second SPF record alongside an existing one. If the domain previously had SPF configured, find and edit that existing record rather than creating a new one. Two SPF TXT records cause an "SPF permanent error" that results in SPF failing for all sends.

Step 3: Add the DKIM CNAME record to your registrar

What to do: Add the Inframail-generated DKIM record as a CNAME entry in your DNS.

Sub-steps:

1. Create a new CNAME record with:
   • Host: the subdomain provided by Inframail (typically selector1._domainkey or similar; enter only the subdomain portion, not the full domain, unless your registrar requires it)
   • Value: the CNAME target provided by Inframail (the long Microsoft 365 path)
   • TTL: 3600 or your registrar's default
2. Save the record
3. Critical: DKIM is a CNAME record, not a TXT record; selecting the wrong record type is a common mistake that produces a record that cannot be used for DKIM verification

Benchmark: Adding the DKIM CNAME record takes 2–5 minutes.

Failure mode: Entering the full domain in the host field when your registrar expects only the subdomain portion. Some registrars auto-append the root domain to CNAME records. If Inframail says the host should be selector1._domainkey and your registrar auto-appends, enter selector1._domainkey.yourdomain.com with a trailing dot (or without the dot, depending on your registrar's convention) to prevent double-appending.

Step 4: Add the DMARC TXT record to your registrar

What to do: Add the DMARC record to begin monitoring email authentication and establish a policy for unauthenticated email.

Sub-steps:

1. Create a new TXT record with:
   • Host: _dmarc (the DMARC record always lives at this subdomain of your sending domain)
   • Value: the DMARC record provided by Inframail (starting with v=DMARC1; p=none)
   • TTL: 3600 or your registrar's default
2. Optionally update the rua= address in the DMARC record to an email you can monitor for DMARC reports; DMARC aggregate reports tell you how many emails are passing or failing authentication
3. Save the record

Benchmark: Adding the DMARC TXT record takes 2–5 minutes.

Failure mode: Setting p=reject immediately. Starting with p=reject before you have confirmed your sending infrastructure is properly authenticated can cause legitimate email to be blocked if any authentication issue exists. Start with p=none, verify your authentication is working for 30 days, then upgrade.

Step 5: Wait for DNS propagation

What to do: Wait for the DNS records to propagate through the global DNS system before attempting verification.

Sub-steps:

1. DNS records typically take 15–60 minutes to propagate to most public DNS resolvers after being saved at your registrar
2. Full propagation (to all DNS resolvers globally) can take up to 48 hours in rare cases
3. Do not create inboxes or attempt authentication verification before the initial propagation window has passed
4. Use a network tool like nslookup or an online DNS lookup tool to check whether your records are visible yet before attempting formal verification

Benchmark: Check propagation at 20 minutes, 60 minutes, and 2 hours. If records are still not visible at 2 hours, review the record entries for typos before waiting the full 48-hour window.

Failure mode: Concluding records are incorrect after only 5–10 minutes. Propagation takes time. The most common support question in DNS setup is "my records aren't working" submitted 5 minutes after adding them.

Step 6: Verify SPF in Inframail and with MXToolbox

What to do: Verify the SPF record is correctly configured and visible using Inframail's verification tool and an external checker.

Sub-steps:

1. In Inframail, navigate to your domain settings and use the "Verify DNS" function; Inframail checks SPF and shows pass/fail status
2. Open MXToolbox's SPF checker and enter your sending domain; it will retrieve and display your SPF record and report any issues
3. Confirm the record includes include:spf.protection.outlook.com
4. Confirm the record ends with -all (hard fail) rather than ~all (soft fail)
5. If SPF is not passing, check for: a second competing SPF record, incorrect @ host entry, propagation delay

Benchmark: SPF verification takes 5 minutes. Both Inframail and MXToolbox should show pass within the propagation window.

Failure mode: Seeing ~all in the SPF record when -all is required. ~all is a soft fail that marks unauthenticated email as suspicious but does not block it. -all is a hard fail that instructs rejecting servers to reject unauthenticated email. Inframail generates the correct qualifier; if ~all appears, verify you copied the complete record.

Step 7: Verify DKIM in Inframail and with a header check

What to do: Verify the DKIM CNAME record is correctly resolving and that outgoing emails are signed.

Sub-steps:

1. In Inframail, use the "Verify DNS" function and check DKIM status; Inframail confirms the CNAME record is resolving correctly
2. Send a test email from your Inframail inbox to a personal Gmail or Outlook account
3. Open the received email and view the email headers (in Gmail: three dots > "Show original"; in Outlook: "View message source")
4. Search the headers for "dkim-signature" and confirm it shows d=yourdomain.com and s=selector1 (or whichever selector Inframail configured)
5. Also check for Authentication-Results: header — it should show dkim=pass

Benchmark: A correctly configured DKIM should show dkim=pass in the authentication results header of a test email sent from the Inframail inbox.

Failure mode: Checking the CNAME record propagation with MXToolbox and seeing the correct CNAME but still getting DKIM fail in email headers. This can indicate that Inframail has not yet completed DKIM key association on the Microsoft 365 side. Wait 24 hours and re-check; Microsoft sometimes takes additional time to associate the key after DNS propagates.

Step 8: Verify DMARC alignment and set monitoring policy

What to do: Confirm DMARC is visible in DNS and that both SPF and DKIM align with the From address domain.

Sub-steps:

1. Use MXToolbox's DMARC checker: enter _dmarc.yourdomain.com and confirm the record is present and correctly formatted
2. Send a test email from the Inframail inbox to a personal Gmail account and view the authentication results header; it should show dmarc=pass
3. Set up DMARC report monitoring: if you added a rua= email address to the DMARC record, expect aggregate reports within 24–48 hours from major providers; these reports show pass/fail counts
4. After 30 days of monitoring with all authentication passing, update DMARC to p=quarantine (move unauthenticated email to spam folder rather than inbox)
5. After another 30 days with p=quarantine and clean reports, update to p=reject (reject unauthenticated email entirely)

Benchmark: DMARC verification takes 5 minutes. The DMARC upgrade timeline (p=none → p=quarantine → p=reject) spans 60 days of clean sending.

Failure mode: Never upgrading from p=none. The p=none monitoring policy provides reporting but no active protection. Upgrading to p=quarantine and eventually p=reject prevents email spoofing from your domain and signals to recipient providers that your domain is actively managed. Most cold email professionals leave DMARC at p=none indefinitely; upgrading provides both a deliverability signal and anti-spoofing protection.

Step 9: Send a pre-campaign authentication test

What to do: Send a test email from each Inframail inbox that will be used for campaigns and confirm all three authentication headers pass.

Sub-steps:

1. From each Inframail inbox (connected to Instantly or another tool), send a test email to a personal Gmail account
2. Open the received email and view the full email source/headers
3. Confirm: spf=pass, dkim=pass, dmarc=pass in the Authentication-Results header
4. Also check for the presence of the X-Microsoft-Antispam header; its presence confirms the email is routing through Microsoft 365 infrastructure
5. If any of the three show "fail" or "none", do not launch campaigns until the issue is resolved

Benchmark: A correctly authenticated email should show all three as pass in the Authentication-Results header. If any fails, return to the relevant step above.

---

Authentication configuration reference for Inframail

Note: Inframail provides the exact DKIM CNAME value for your specific domain; the pattern above is illustrative.

---

Advanced tactics

Tactic 1: Add a custom DMARC reporting email and review reports weekly

DMARC aggregate reports (sent to the rua= address in your DMARC record) contain data on every email that claims to be from your domain: how many passed SPF, how many passed DKIM, how many were rejected, and which IP addresses sent them. This data reveals whether anyone is spoofing your domain to send unauthorized email — a security issue as well as a deliverability one.

Set the rua= address to a dedicated email (dmarc@yourdomain.com works) and review the reports weekly during the first 30 days. The reports arrive as XML files from major providers (Google, Microsoft, Yahoo). DMARC report tools like dmarcian or Google's Postmaster Tools aggregate these reports into readable dashboards.

If you see sends from IP addresses you do not recognise passing SPF, investigate immediately: it may indicate that a previous provider's include still exists in your SPF record and is authorising unauthorised senders.

Tactic 2: Verify authentication with a dedicated inbox placement test tool

MXToolbox verifies that DNS records exist and are correctly formatted. What it cannot do is confirm that the records are being used correctly for outgoing email signing. For end-to-end verification, use an inbox placement testing tool like GlockApps or Mail-Tester.

These tools provide a unique test email address. Send an email from your Inframail inbox to this address. The tool then shows: inbox vs. spam placement rate, authentication pass/fail status (SPF, DKIM, DMARC) as seen by actual recipient mail servers, spam score based on content and authentication, and technical headers for detailed analysis.

A score of 8/10 or above on Mail-Tester with all three authentication checks passing is the target before launching campaigns.

Tactic 3: Set DMARC to p=reject for maximum spoofing protection and deliverability signalling

Recipient mail servers use DMARC policy as a signal about how seriously a domain owner manages authentication. A domain with p=reject signals active, mature email management. A domain with p=none signals monitoring-only, which is the minimal compliance posture.

The 60-day DMARC upgrade path (none → quarantine → reject) is conservative but safe. If you have high confidence your authentication is correctly configured from day one — Inframail's automation makes this more likely — you can accelerate the upgrade: p=quarantine after 14 days of clean DMARC reports, p=reject after another 14 days.

Never jump to p=reject without at least 14 days of DMARC report review at p=quarantine. The reports may reveal legitimate email flows you were unaware of (third-party systems sending on your behalf) that would be blocked under p=reject.

Tactic 4: Add a second DKIM selector for key rotation

Microsoft 365 supports two DKIM selectors (selector1 and selector2). Inframail configures one by default. Adding a second CNAME record for the second selector enables DKIM key rotation — the process of switching from one signing key to another without service interruption.

For cold email operations running at high volume over long periods, annual DKIM key rotation is a security and deliverability best practice. If a private key is ever compromised, rotation allows you to switch to the clean key without changing the email address or domain.

Contact Inframail support to enable the second selector; they will provide the second CNAME record value to add to your DNS.

Tactic 5: Test authentication from each inbox individually, not just the domain

Inframail configures authentication at the domain level (one set of records per domain). But if you have multiple inboxes on the same domain, confirm that each inbox is using the domain's DKIM signing key correctly. This is typically automatic, but in some Microsoft 365 configurations, individual mailboxes can override signing settings.

Send a test email from each inbox and check the Authentication-Results header of the received email. All inboxes on the same domain should show the same DKIM selector and d=yourdomain.com in their DKIM signature. If any inbox shows DKIM signing with a different domain or fails DKIM, investigate that specific inbox's Inframail configuration.

---

Troubleshooting SPF, DKIM, and DMARC failures

Problem 1: SPF failing despite having the correct SPF record

Symptoms: MXToolbox shows your SPF record is correctly formatted but authentication results headers on test emails show spf=fail.

Diagnosis steps:

1. Check whether there are two SPF TXT records on the domain — having more than one SPF record causes an SPF "permerror" that results in fail
2. Check whether you have exceeded the 10 DNS lookup limit in your SPF record; complex SPF records with many include statements can exceed the limit
3. Verify the sending IP is actually in the Microsoft 365 IP ranges — if emails are routing through a non-Microsoft relay for some reason, they will fail SPF

Fix: Combine all SPF content into a single TXT record. If you have multiple include statements, remove any from previous providers no longer in use. If lookup limit is the issue, use an SPF flattening service to convert the include statements to explicit IP ranges.

Problem 2: DKIM failing with "no key for signature"

Symptoms: Authentication headers show dkim=fail (no key for signature) despite having added the CNAME record.

Diagnosis steps:

1. Check DNS propagation: the CNAME may not have propagated yet; wait 60 minutes and re-check
2. Verify the CNAME host is correct — a common error is entering the host as selector1._domainkey.yourdomain.com when the registrar auto-appends the domain, making it selector1._domainkey.yourdomain.com.yourdomain.com
3. Check whether the CNAME was entered as a TXT record instead of a CNAME record

Fix: Use MXToolbox to query the CNAME directly and see what it resolves to. If it returns an error or resolves to the wrong value, re-enter the CNAME from scratch in your DNS panel.

Problem 3: DMARC failing despite SPF and DKIM passing

Symptoms: Authentication headers show spf=pass and dkim=pass but dmarc=fail.

Diagnosis steps:

1. DMARC requires alignment, not just pass: the SPF domain or DKIM signing domain must match the From header domain exactly
2. Check whether the SMTP envelope sender domain (the technical routing address) matches your From domain; if not, SPF may pass but DMARC SPF alignment fails
3. Check whether the d= value in the DKIM signature matches your From domain exactly (including subdomain differences)

Fix: For cold email using Inframail with the From address matching the domain on which DKIM is configured, alignment should be automatic. If DMARC is failing despite both SPF and DKIM passing, the most common cause is a sending tool (Instantly, Smartlead) routing through a subdomain or relay that changes the envelope sender. Check the full email headers to identify the envelope sender domain.

Problem 4: DNS record appearing correctly but still not passing in Inframail's verification

Symptoms: MXToolbox shows the record is correctly formatted and propagated, but Inframail's internal DNS verification still shows fail.

Diagnosis steps:

1. Inframail may be checking a specific DNS resolver that has not yet received the propagation update; wait additional time
2. Check whether Inframail's verification is looking for an exact match that differs from what you entered (e.g., expecting the record to end with a period, or checking the full FQDN rather than the relative host)

Fix: Wait 2–4 hours and re-verify in Inframail. If MXToolbox shows the record correctly and Inframail still shows fail after 4 hours, contact Inframail support with the MXToolbox verification results.

Problem 5: DMARC aggregate reports showing unknown senders passing SPF

Symptoms: DMARC reports show email from IP addresses you do not recognise with your domain in the From header, and those emails are passing SPF.

Diagnosis steps:

1. Check your SPF record for any include statements from previous providers that are still authorising their servers
2. Check whether any third-party tool (CRM, marketing platform, transactional email provider) is sending on behalf of your domain using its own SMTP relay

Fix: Remove SPF include statements for services you no longer use. For legitimate third-party services that need to send on your behalf, keep their include statement but document it. For unauthorised senders, the p=reject DMARC policy will block them after you upgrade from p=none.

Problem 6: DKIM failing specifically for emails sent through Instantly

Symptoms: Test emails sent directly from Inframail pass DKIM, but emails sent through Instantly using the same inbox fail DKIM.

Diagnosis steps:

1. Check whether Instantly is modifying email headers or content in transit in a way that invalidates the DKIM signature
2. Verify that Instantly is using STARTTLS for the SMTP connection, not plain text; a plaintext connection could allow content modification that breaks DKIM
3. Check the DKIM signature in the Instantly-sent email: the b= (signature) and bh= (body hash) values should be present

Fix: Ensure the Instantly SMTP connection uses STARTTLS (port 587). If using port 25 or an unencrypted connection, switch to port 587 with STARTTLS. If the issue persists, contact Instantly support with the full email headers for analysis.

---

What practitioners say about authentication setup with Inframail

A verified user on Inframail reviews on G2:

"Before Inframail, I was manually setting up DKIM for every domain and it was the step I dreaded most. Microsoft's DKIM setup for custom domains requires enabling it through the Microsoft 365 admin centre and then managing CNAME records carefully. Inframail handles all of that automatically. I add the domain, copy three records, and authentication is done."

— Verified buyer on Inframail reviews on G2

A thread in r/coldemail (891 upvotes):

"SPF, DKIM, and DMARC all need to pass for good deliverability — this is non-negotiable. The confusion is that they solve different problems. SPF = right server. DKIM = untampered message. DMARC = policy + alignment + reporting. All three together provide comprehensive authentication. Any one missing creates a gap."

— r/coldemail, 891 upvotes

A second reviewer on Instantly reviews on G2:

"The authentication headers in the test email are the thing to check. When I connect a new inbox to Instantly, I immediately send a test to a Gmail account and look at the headers. SPF pass, DKIM pass, DMARC pass. If any of the three show fail, I stop and fix before launching anything. Non-negotiable rule."

— Verified buyer on Instantly reviews on G2

---

Our actual stack

---

Frequently asked questions

What is the difference between SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) verifies that the server sending the email is authorised to send on behalf of your domain by checking a DNS list of authorised servers. DKIM (DomainKeys Identified Mail) cryptographically signs outgoing emails with a private key, allowing recipient servers to verify the email has not been tampered with in transit using the public key from DNS. DMARC (Domain-based Message Authentication, Reporting, and Conformance) adds a policy layer that tells recipient servers what to do when SPF or DKIM fails, and provides reporting on authentication pass/fail rates.

Do I need all three, or can I just set up SPF?

All three are required for full authentication benefit. SPF alone can be bypassed through envelope sender spoofing. DKIM alone can be stripped in some relay configurations. Without DMARC, there is no consistent policy for how recipient servers handle authentication failures. The three work together as a system: SPF verifies the server, DKIM verifies message integrity, DMARC provides policy enforcement and alignment verification.

Does Inframail set up SPF, DKIM, and DMARC automatically?

Inframail auto-generates the correct records for its Microsoft 365 infrastructure and displays them in your account. You must add these records to your registrar's DNS panel manually — Inframail does not have write access to your DNS directly. The generation is automatic; the DNS panel copy-paste is manual.

How long does DNS propagation take for the authentication records?

Most records propagate to public DNS resolvers within 15–60 minutes. Full global propagation can take up to 48 hours in rare cases. Check propagation at 20 minutes and 60 minutes after adding records. If records are not visible at 60 minutes, check your registrar's interface to confirm the records were saved correctly.

What does p=none in the DMARC record mean?

p=none is the monitoring-only DMARC policy. It instructs recipient servers to take no special action on email from your domain that fails authentication — just report the failure back to you via DMARC aggregate reports. It is the safe starting policy for DMARC setup. After 30 days of monitoring with all authentication passing cleanly, upgrade to p=quarantine and then to p=reject.

What DMARC policy should I use for cold email?

Start with p=none for the first 30 days. This allows monitoring without the risk of blocking legitimate email if any authentication issue exists. After 30 days of clean DMARC reports, upgrade to p=quarantine. After another 30 days, upgrade to p=reject. Upgrading DMARC policy signals active email management to recipient providers and provides anti-spoofing protection.

Why is my DKIM record a CNAME and not a TXT record?

Microsoft 365 DKIM configuration uses CNAME records that point to Microsoft's key management infrastructure. This approach allows Microsoft to rotate DKIM keys automatically without requiring you to update your DNS records each time. The CNAME points to Microsoft's infrastructure, which publishes the current public key at that location.

How do I check if my authentication records are working?

Send a test email from your Inframail inbox to a personal Gmail account. In Gmail, open the email, click the three dots, and select "Show original." In the message headers, look for the Authentication-Results: line. It should show spf=pass, dkim=pass, and dmarc=pass. Any "fail" or "none" indicates an issue requiring resolution.

What happens if emails fail authentication?

Without passing SPF, DKIM, and DMARC, emails go to spam or are rejected outright by major providers. Gmail and Microsoft Outlook both use authentication failures as a strong spam signal. Since February 2024, Google requires bulk senders (those sending 5,000+ emails per day) to have SPF and DKIM configured; DMARC is recommended.

Can I set up authentication for multiple sending domains in Inframail?

Yes. Add each sending domain to Inframail separately. Inframail generates a separate set of SPF, DKIM, and DMARC records for each domain. Add each domain's records to the corresponding DNS panel at your registrar. Authentication is configured per domain; inboxes on different domains have independent authentication records.

---

Set up your authenticated inboxes and order verified contacts

Authenticated inboxes are only effective when sending to verified contacts. High bounce rates from unverified lists damage the sender reputation that authentication helps build.

Quarvio delivers pre-verified B2B contacts at $129 for 5,000 contacts through $699 for 50,000 contacts. 90% deliverability guarantee, 12-month credit validity, unused credits carry forward.

Start your contact order at Quarvio →