Why a new domain fails to deliver — even with clean lists

You've cleaned your list. Verified every address. Even used a tool like MailTester to weed out invalid domains. But your first campaign still lands in spam, or worse—vanishes into the void.

That’s not a list problem. It’s a domain problem. A new domain has zero sender reputation. ISPs see it as unproven, suspicious. Even if every recipient is valid, the envelope gets rejected before the message even opens.

Spammers don’t just target bad lists—they target weak domains. Without proper DNS setup—SPF, DKIM, DMARC—your domain is invisible to email gateways. They can’t verify you’re real, so they assume you’re not.

Authentication isn’t a formality. It’s the foundation. Without it, no amount of list hygiene matters. This guide walks through the only DNS checklist you need before day one: SPF, DKIM, DMARC, and how they actually work together in practice.

Key takeaways

  • SPF, DKIM, and DMARC must be set before sending to any new domain—failure to do so results in inbox placement failure regardless of list quality.
  • ISPs treat new domains with suspicion; authenticating DNS records is how you prove legitimacy in the absence of sender reputation.
  • Without correct DNS configuration, even valid email addresses will be blocked—authentication is not optional, it's mandatory for deliverability.

What happens if you skip DNS setup before warm-up?

You risk your first emails being blocked, sent to spam, or silently dropped—especially if SPF, DKIM, and DMARC aren’t properly configured before starting your warm-up. Without them, ISPs see your domain as unverified, increasing the chance of being flagged as spam or treated with suspicion. This undermines trust from the start.

Spam traps and reputation risk

Many domains have dormant spam traps—old email addresses used to catch spammers. If you send before warming up and those addresses are in your list, you trigger a trap. That damages your sender reputation instantly, even if you never sent a single marketing email to a real user. Sending to such addresses is a common red flag for ISPs and can land you on blocklists without warning.

DMARC policies can block or quarantine your messages if authentication fails. If you don’t set up SPF and DKIM correctly, DMARC evaluates that as a failure. Then, even if your content is clean, the message may be rejected or marked as untrusted. This happens silently—no bounce, no notification—so you won’t know your emails never landed.

Warm-up fails without authentication

Warm-up isn’t about sending volume—it’s about building a trust signal with ISPs over time. Sending 500 emails to inactive lists with no authentication is like arriving at a party with no ID. ISPs ignore you or flag you as suspicious. You’re not building reputation; you’re risking it.

Auth records like SPF, DKIM, and DMARC are the foundation of email legitimacy. Skipping them means every message lacks a verifiable identity. Even if your content is great and your list is clean, you're starting the process with a credibility gap. This makes it harder to get your messages through the filters that determine inbox placement.

For a real check, run your domain through a verification tool before warm-up. You can test if SPF, DKIM, and DMARC are set up correctly via MailTester’s inbox placement tester—it runs a full deliverability simulation. Even better, validate your entire list first using bulk verification to clean bad addresses and catch traps early.

Standards like RFC 7208 (DMARC) and RFC 5321 (SMTP) define how ISPs evaluate messages. When you skip DNS setup, you’re ignoring the very standards that govern email delivery. It’s like building a car without wheels—just because it looks like a car doesn’t mean it’ll move.

The core DNS records that must be live before day one

You need SPF, DKIM, and DMARC set up and validated in DNS before sending your first email. SPF authorizes sending servers, DKIM signs messages to prevent tampering, and DMARC tells receivers what to do with unauthorized or unauthenticated mail. Without all three, your domain risks being rejected, marked as spam, or bypassed entirely—especially on large platforms like Gmail and Outlook. These records must be live, correctly configured, and tested before any warm-up begins.

SPF: Authorize your sending sources

SPF defines which IP addresses or mail servers are allowed to send emails from your domain. It’s the first line of defense. If your sending infrastructure includes multiple providers—like SendGrid, Mailchimp, or a custom smtp server—you must list all valid sources.

Misconfigured SPF can cause hard bounces or cause emails to be treated as suspicious. A single domain can have only one SPF record; multiple records will fail validation.

DKIM: Ensure message integrity

DKIM adds a digital signature to each outgoing email. Recipients verify this signature using a public key published in DNS. This confirms the message was not altered in transit and truly came from your domain.

Without DKIM, some mailbox providers may reduce trust in your emails, especially during warm-up. You must generate a private key to sign messages and publish the corresponding public key in DNS.

DMARC: Enforce policy and receive feedback

DMARC ties SPF and DKIM together. It tells receivers what to do if either fails—reject, quarantine, or allow. It also enables you to receive reports about authentication failures, which helps you spot spoofing or misconfigurations.

Start with a p=none policy to monitor without blocking. Then, gradually escalate to p=quarantine or p=reject after confirming your legitimate senders are properly authenticated.

Record Role How it works Common mistakes
SPF Sender authorization Defines which IPs or services can send on your behalf. Checked at envelope time during SMTP. Multiple SPF records, too many include mechanisms, using ~all instead of -all for production.
DKIM Message integrity Digitally signs each email with a private key. Public key lives in DNS for validation. Missing or expired keys, misconfigured selector, not signing all outbound mail.
DMARC Policy enforcement & reporting Enforces SPF/DKIM requirements. Delivers feedback reports to help monitor compliance. Setting policy to reject too early, ignoring reports, no monitoring infrastructure.

For real-time DNS validation—before sending, before warm-up, or before launching—verify your records with tools like MXToolbox or RFC 7483. Run your entire list through a bulk email verification service that checks DNS, domain reputation, and deliverability risk to catch issues early. Use the API to automate this across your onboarding or campaign workflows.

How to verify SPF, DKIM, and DMARC settings are correct

You don’t need to wait for your first email to test your DNS records. Use public tools like MxToolbox or the command-line dig to confirm your SPF, DKIM, and DMARC TXT records are published correctly. Start DMARC in monitoring mode (p=none) to collect data before enforcing policies. Align DKIM keys with your sending domain and verify all addresses resolve without being catch-alls. These steps reduce bounce rates and protect your sender reputation from day one.

Step-by-step verification process

  1. Check SPF record publication using a DNS lookup tool like MxToolbox or dig txt yourdomain.com. Ensure the record includes your sending IPs or mail service (e.g., spf.protection.outlook.com). A missing or malformed SPF can cause delivery fails.
  2. Verify DKIM key publication by checking the TXT record at the selector.yourdomain.com subdomain (e.g., default._domainkey.yourdomain.com). The key must match your sending system’s configuration. Misaligned or missing DKIM records cause authentication failures during delivery.
  3. Confirm DMARC policy status by querying your _dmarc.yourdomain.com TXT record. Set the policy to p=none initially. This allows you to monitor email authentication reports from providers like Gmail and Yahoo without blocking legitimate mail. Enforcing p=reject too early risks dropping valid messages.
  4. Test alignment between SPF and DKIM. Both must pass for the same domain or subdomain. You can use RFC 7073 as reference for alignment rules. Misalignment triggers rejection by strict DMARC policies.
  5. Verify real addresses before sending using a tool like MailTester’s bulk verification. This checks whether individual addresses exist, aren’t catch-alls, and aren’t disposable. Catch-alls absorb mail but don’t deliver, inflating your sender reputation score artificially.

What to watch for

Even with correct DNS, some domains appear valid but are actually catch-alls or role addresses (e.g., admin@, contact@). These don’t reliably receive mail and hurt your sender reputation. Use a real-time email verification API like MailTester’s email checker to assess individual addresses during onboarding or list cleanup. This helps avoid high bounce rates during warm-up.

Early testing pays off: a single misconfigured record can lead to delivery failures or blacklisting, even at scale.

After setup, run inbox placement tests with MailTester’s inbox tester to see how your first emails land across major providers. This gives you a real-world preview before your warm-up starts.

New domain warm-up DNS checklist: step by step

You need to set up SPF, DKIM, and DMARC records before sending emails from a new domain. Publish them correctly, test them with a tool like MailTester’s API, and ensure they’re live at least 48 hours before your first send. This prevents bounces, blocks, and spam filter suspicion. Let’s walk through it.

  1. Create an SPF record that lists only the mail services you’ll use—like SendGrid, Mailchimp, or your own server. Avoid including untrusted providers. An SPF record tells receivers which servers are allowed to send on your behalf. A mismatch here triggers spam filters.
  2. Generate a DKIM key pair and publish the public key in DNS as a TXT record. DKIM signs outgoing messages so receivers can verify they haven’t been altered. Most ESPs generate this automatically when you enable it in your dashboard.
  3. Set a DMARC record with rua and ruf URIs pointing to your email address or a dedicated reporting inbox. This allows you to receive reports on authentication failures, which helps detect spoofing or misconfigurations.
  4. Test all DNS records using a tool like MXToolbox or via MailTester’s real-time verification API. Ensure no errors or warnings appear—especially for SPF or DKIM alignment.
  5. Wait 48 hours after publishing records before your first email send. DNS propagation can take time, and receivers like Gmail or Outlook may reject messages from domains with unverified authentication during that window.
  6. Check for conflicts. Ensure you don’t have multiple SPF records. If you do, merge them into one. Also verify no TXT record exceeds 255 characters—split long ones into multiple records as needed.
  7. Run an inbox placement test using a real tool like MailTester’s inbox tester. Send a message to a sample inbox and observe how spam filters react. This simulates what a real recipient will see.

Why timing and testing matter

Spammers and fraudsters often target new domains with weak authentication. If your DNS records aren’t fully published and tested before sending, even legitimate messages get flagged. Major providers like Google and Microsoft require strong authentication for inbox placement.

Use real tools, not guesses

Don’t rely on generic checkers. Use a tool that validates across multiple protocols and gives actionable insights. MailTester’s integrations with HubSpot, Klaviyo, and SendGrid streamline this process for teams already in the workflow. With 98.9% accuracy, it’s a trusted instrument for validating domain readiness.

SPF vs DKIM vs DMARC: their distinct roles in email security

You need SPF, DKIM, and DMARC to secure your domain before sending email. SPF checks if your sending IP is authorized. DKIM confirms the message content hasn’t changed since it was signed. DMARC tells ISPs what to do with emails that fail either check — like reject or quarantine. Together, they’re the foundation of sender reputation.

How Each Protocol Works in Practice

Let’s break down what each does, without jargon.

Protocol What It Checks Who Uses It Common Failures
SPF Whether the sending IP is listed in the domain’s TXT record as authorized. Receiving servers (e.g., Gmail, Outlook). IP not in policy, multiple SPF records, overlong records, missing include.
DKIM Whether the message content matches the digital signature attached. Receiving servers, spam filters. Invalid or expired key, incorrect headers, misconfigured selector, header changes.
DMARC Combines SPF and DKIM results and enforces policy (e.g., reject, quarantine) on failures. ISPs, anti-abuse systems, postmaster teams. No policy set, policy too strict, poor reporting, missing alignment.

SPF is about sending authority. DKIM is about message integrity. DMARC is about enforcement. Without all three, your domain appears untrusted—even if you’re not sending spam.

Why They Matter Before Day One

Even a single failed SPF or DKIM check can send red flags to Gmail or Microsoft. ISPs use DMARC reports to detect abuse patterns. If your domain lacks a DMARC policy, it’s effectively invisible to abuse monitoring systems. This means your messages may go straight to spam or be blocked.

Use tools like MailTester’s inbox placement tester to verify how your setup performs in real inboxes. It checks SPF, DKIM, and DMARC alignment automatically across major providers.

For deeper validation, verify your email list before sending. Catch-all addresses, disposable domains, and invalid formats can trigger warnings in DMARC and other systems.

These protocols are standardized. See SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) for technical details. Real-world deployment is where the complexity lies—not the specs.

Avoid common DNS configuration mistakes in new domains

You’re setting up a new domain for email outreach, and the DNS configuration is your first line of defense. Mistakes here—like duplicate SPF records, excessive mechanisms, or misconfigured DKIM—can trigger bounces, spam filters, or outright rejection before your first message even leaves your server. Let’s walk through the most common pitfalls and how to avoid them.

SPF: Only one record allowed, and it must be efficient

  • Do not create multiple SPF records. Only one is allowed per domain; additional records are ignored or cause a permanent fail.
  • Use include mechanisms sparingly. Each one counts toward the 10-dns-lookup limit—exceeding it can result in a temporary failure.
  • If you're using third-party sending services, ensure they’re included with include:provider.com, not duplicated across multiple records.

DKIM and DMARC: Precision prevents reputational harm

  • Verify that the sending domain is part of the DKIM signature selector. A misaligned selector—like using default for [email protected] but signing with [email protected]—breaks authentication.
  • Never reuse the same DKIM selector across multiple domains. Each domain should have a unique selector, or you risk alignment issues and possible spoofing detection.
  • Set DMARC policy to p=none initially. Switching to p=reject too early can cause legitimate emails to be blocked if authentication is imperfect. Monitor reports for 7–14 days before enforcing.
Even small misconfigurations can signal bad actor behavior to receiving servers. A single malformed SPF or DKIM record can tank deliverability before day one.

Double-check your DNS records with a real-time tool before sending test emails. Tools like MXToolbox or RFC 7208 (SPF specification) help validate syntax and structure.

If you’re managing a large list or sending from multiple domains, use MailTester’s bulk verification to catch invalid, catch-all, or role-based addresses early. The API is ideal for validating addresses in real time during signup or onboarding. Test inbox placement with our inbox tester to simulate real sender behavior. And for teams using platforms like SendGrid, HubSpot, or Klaviyo, integrate with our native connectors to maintain clean data at scale. You get 100 free verifications to start—no expiry on purchased credits.

Can you trust a domain’s DNS records without verification?

No, you cannot. DNS records may appear correct in a public checker but still fail in real delivery due to propagation delays, caching, or configuration errors. A domain can show as authenticated on paper but still be blocked or rejected in practice. Always verify your DNS setup with a service that tests live sending behavior before Day One.

Why published DNS records lie sometimes

Even if your SPF, DKIM, and DMARC records show up correctly in a DNS lookup, they may not be active yet. DNS changes can take hours to propagate globally — some resolvers cache records for days. A record might be technically correct but not yet visible to mail servers in key regions.

Moreover, small typos in TXT records — like a missing space or mismatched domain — can break authentication without being obvious in a quick check. One miswritten tag can cause your emails to fail DMARC alignment, even if all other settings look fine.

As outlined in RFC 5321 and RFC 5322, the SMTP protocol does not validate DNS records before transmission. It only enforces rules during the handshake. That means a domain may "pass" a DNS query but still get bounced by a receiving server with strict policies.

Test like a real sender, not a scanner

Instead of relying on public DNS tools, simulate real-world sending. Services like MailTester’s inbox placement test send actual emails through major providers (Gmail, Yahoo, Outlook) to validate whether your domain, IP, and DNS setup actually work in practice.

Our inbox tester checks SPF, DKIM, and DMARC alignment in a live environment, including catch-all detection and greylisting responses. This reveals whether a domain is truly deliverable — not just technically valid.

With MailTester’s bulk verification or real-time API, you can test hundreds of domains before your first campaign. The results include not just “valid” or “invalid,” but also risk indicators like catch-all status or role account detection — problems that can harm sender reputation if ignored.

For teams using Mailchimp, HubSpot, Klaviyo, or SendGrid, the integration with MailTester’s verification ensures your domain is warm and deliverable before your campaign goes live. You’re not just checking records — you’re validating deliverability from day one.

Verify before you send. Test your domain’s inbox placement today to catch hidden issues early.

MailTester: real-time verification and inbox placement tests before send

You can verify entire email lists in real time, test how messages land in Gmail, Outlook, and Yahoo inboxes, and validate SPF, DKIM, and DMARC alignment—all before your first send. Let’s walk through how.

Verify and test your lists before sending

  • Use MailTester’s bulk verification API at https://mailtester.com/api-email-checker to scan your list and flag invalid, catch-all, or risky addresses before you send.
  • Run inbox placement tests on https://mailtester.com/inbox-tester to see how your message lands in real inboxes—no guesswork, just real delivery results across major providers.
  • Confirm SPF, DKIM, and DMARC records are correctly set and aligned using automated validation checks that catch misconfigurations before they harm your sender reputation.

Integrate and clean up your workflow

  • Connect MailTester with Mailchimp, HubSpot, Klaviyo, or SendGrid via https://mailtester.com/integrations to auto-clean lists prior to sending—no manual work.
  • Filter out domains that don’t handle mail (like @example.com or role-based addresses) and identify catch-all domains that accept all emails, helping you avoid wasted sends.
  • Verify each address’s real-time status, including whether it’s disposable or likely to bounce (e.g., invalid syntax or hard bounces), based on SMTP response and DNS checks.

Every deliverability issue starts with the foundation: a clean list and proper authentication. By testing at scale before sending, you avoid unnecessary bounces, blocked messages, and reputational harm.

According to RFC 7897, SPF, DKIM, and DMARC are foundational to email trust. When these are off, even a well-written message won’t get past filtering.

MailTester’s 98.9% accuracy comes from checking live SMTP responses, reverse DNS, and domain reputation in real time—not just syntax or pattern rules. That means fewer false positives and fewer wasted sends.

Start with 100 free verifications at https://mailtester.com/pricing—no expiry, no strings. Test your list, validate your DNS, and get your first send right.

The deliverability cost of rushing warm-up without DNS prep

Skipping DNS setup before warm-up invites bounces, blacklists, and reputation damage. Without SPF, DKIM, and DMARC in place, even a single sent email may be rejected or flagged. This harms deliverability from day one, especially if early emails land in spam or never arrive. Use MailTester’s bulk verification to catch invalid addresses before you send.

Why DNS prep isn’t optional — even on launch day

You can’t warm up a sender reputation with a broken foundation. If SPF isn’t configured, receivers can’t verify your domain is authorized to send. Without DKIM, messages lack cryptographic proof of authenticity. DMARC tells receivers what to do with failed checks. Skipping any of these leaves your emails vulnerable to rejection or spam filtering.

Consider this: a single misrouted email to a spam trap — often a legacy or invalid address — can trigger filters and get your IP or domain blocked. Many ISPs use automated systems that monitor early engagement patterns. If you send to addresses that aren’t real or don’t respond, reputation scores dip fast.

What happens when you skip the checklist

High bounce rates in the first 48 hours? That’s a red flag. ISPs and email providers track how many emails fail to deliver. A bounce rate above 2% can mark you as unreliable. If you’re using a new domain and your first messages don’t reach inboxes, your sender reputation starts with a deficit.

Even a small number of failed deliveries can expose your infrastructure to spam traps. These aren’t new accounts — they’re dead or abandoned email addresses monitored by anti-spam systems. Landing one message in these traps counts as a violation, even if unintended. This can lead to IP reputation blacklisting or domain-level filtering.

Over time, low engagement from early campaigns — because emails go nowhere or land in spam — trains filters to ignore future messages. The recipient doesn’t open them, so the message gets flagged as low value. And if every first email hits the same issue, engagement stays flat, reputation stalls.

Let’s be clear: warm-up isn’t just about sending small volumes. It’s about sending reliably. That requires proper DNS records, a clean list, and inbox placement testing. That’s why inbox placement testing should be part of your pre-launch routine. It shows whether your emails reach inboxes — before you send to real users.

For ongoing verification, the Email Verification API integrates directly into your workflow. It checks real-time against known traps, disposable domains, invalid addresses, and catch-alls. You’ll find that catching issues early — before sending — saves more than just deliverability. It preserves sender trust, both from the inbox and the network.

Final checklist: confirm DNS and domain readiness before sending

Before sending your first email from a new domain, ensure every DNS record is published, aligned, and verified. Syntax errors in SPF or misaligned DKIM can trigger rejection. Always validate records using public tools before proceeding.

Test the entire flow: verify that no addresses are catch-all, inbox placement is stable across providers, and domain warm-up begins with minimal volume. This prevents spam filter flags and builds sending reputation gradually.

  1. SPF record published and validated (no syntax errors).
  2. DKIM key published and aligned with sending domain.
  3. DMARC record published with monitoring enabled (p=none).
  4. All records propagated and visible via DNS check tools.
  5. All test emails verified as valid and non-catch-all.
  6. Inbox placement test completed across multiple email providers.
  7. Domain warm-up sequence scheduled with low volume and gradual increase.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

How long does DNS propagation take before warm-up?

DNS changes typically propagate within 1 to 48 hours. Allow at least 48 hours before sending your first email to avoid delivery failures.

Can you use multiple sending providers with one SPF record?

Yes, but only if listed in the same SPF record using the include mechanism. Avoid overloading it with too many includes.

What does DMARC p=none mean?

It means messages failing authentication will be delivered but reported to the domain owner. It's the safest starting policy during warm-up.

Why do some domains still get blocked despite proper DNS setup?

SPF alignment may fail if the sender domain doesn’t match the From header. DKIM alignment with the From domain can also fail. These are common missteps in configuration.

Does MailTester check SPF alignment?

Yes. MailTester verifies DNS records and checks alignment between SPF, DKIM, and the From address during inbox placement tests.

Can I skip warm-up if I have strong authentication?

No. Strong authentication improves inbox placement but does not replace reputation building. Warm-up remains necessary for new domains.

How do I know if my DKIM key is correct?

Verify the public key is published in DNS and that messages sent from your domain appear signed in email headers.

What happens if I set DMARC to p=reject too early?

Legitimate emails may be rejected if SPF or DKIM fails. This is risky during warm-up and can break delivery.

Can MailTester help with bulk list cleaning?

Yes. MailTester's bulk verification checks for invalid, catch-all, role, and disposable addresses before sending.

Do purchased credits in MailTester expire?

No. All purchased credits never expire, giving you flexibility to verify lists as needed.