How to Configure DNS for Email Sending with Gmail or Outlook

Why DNS Configuration Matters for Email Sending

You send a perfectly valid email to a client. It doesn’t arrive. No bounce, no error — just silence. Why? Because your email’s journey doesn’t start when you hit “send.” It starts with DNS records your domain must publish.

Even the most accurate email list fails if your domain’s DNS settings are wrong. Gmail and Outlook rely on SPF, DKIM, and DMARC records to decide if your message is real or spoofed. Missing or incorrect records mean your email is marked as spam, delayed, or blocked — no exceptions.

Configuring DNS correctly isn’t just technical busywork. It’s the foundation of deliverability. Without it, your messages never reach the inbox, no matter how well-written or timely they are. The key to inbox placement is not just your content — it’s your domain’s reputation, built on proper DNS setup.

Key takeaways

• Improper DNS settings are the top reason valid emails fail to deliver, even with correct addresses.
• Gmail and Outlook use SPF, DKIM, and DMARC records to validate senders and prevent spoofing.
• Missing or misconfigured DNS records lead to spam filtering, delays, or outright rejection.

The Three Core DNS Records for Email Sending

Setting up email authentication isn’t optional if you want your messages to land in inboxes, not spam folders. You’re not just sending mail—you’re proving you’re authorized to send it. Let’s walk through the three DNS records that form the backbone of email deliverability.

SPF: Your Domain’s Permission List

SPF tells receivers which servers are allowed to send emails on your domain’s behalf. Without it, your emails are likely to fail authentication checks. You define it in a TXT record, listing IP addresses or service providers like Gmail, Outlook, or your ESP.

For example, if you use both Gmail and SendGrid, your SPF record might include both providers. But remember: SPF has a limit. You can’t have more than 10 DNS lookups per check. If you exceed that, SPF fails—so keep your list lean.

Learn more about SPF limits in RFC 7208, the official specification here.

DKIM: The Digital Seal

DKIM adds a cryptographic signature to each outgoing email. Recipients verify this signature using a public key stored in your domain’s DNS. If the email is altered in transit—even a single character—the signature fails.

It’s not about who sent it, but whether it arrived untouched. DKIM is especially useful when using third-party tools or ESPs, since they can sign emails on your behalf.

Check the basics of DKIM in RFC 6376: here.

DMARC: The Enforcement Policy

DMARC tells receiving servers what to do when SPF or DKIM fails. It’s your domain’s policy: “Reject,” “Quarantine,” or “Monitor.” You also get reports on failed deliveries, which helps you spot spoofing attempts.

Setting DMARC to “monitor” (p=none) is a good start. It lets you track issues without blocking delivery. Later, you can tighten it to “quarantine” (p=quarantine) or “reject” (p=reject).

These three records work together. SPF vetoes unauthorized senders, DKIM guarantees message integrity, and DMARC tells the world how to respond when things go wrong.

If you're verifying a list before sending—or checking whether your domain is properly authenticated—MailTester’s inbox placement test or bulk verification can help you audit your domain’s configuration and catch issues early.

How SPF Works: Defining Authorized Sending Servers

Let’s get one thing straight: SPF isn’t about encryption or authentication—it’s about telling receivers, “These servers are allowed to send emails from your domain.”

The SPF Record in DNS

SPF uses a DNS TXT record to list the IP addresses, domains, or third-party services authorized to send mail on your behalf. This record lives in your domain’s DNS zone and is checked by receiving mail servers during delivery.

For example, if you use Gmail to send emails from your domain (like [email protected]), you’ll include Google’s SPF: v=spf1 include:_spf.google.com ~all. That tells servers, “Yes, Google’s infrastructure can send emails for me.”

But here’s where it gets tricky: the ~all at the end means “soft fail” for any server not listed. If you have multiple includes or overly broad rules, the receiver might reject your email outright.

Common Pitfalls and Fixes

Too many include directives—especially from overlapping services—can cause SPF hard failures. Each include adds complexity, and some systems don’t handle more than 10 includes well.

Let’s say you use Gmail, SendGrid, and HubSpot. You don’t need to include all three SPF records blindly. Instead, list only the essential ones, and avoid duplicating or nesting includes unnecessarily.

As a rule, fewer is better. Only include the services you actually use. This keeps the record clean, reduces the risk of policy conflicts, and improves deliverability.

When in doubt, check your DNS setup with a trusted tool like MXToolbox or RFC 7208, the official SPF standard. These tools show whether your record is parsed correctly and help catch syntax issues before they cause bounces.

Even better, verify your email addresses and domain configuration beforehand. Use an email verification tool like MailTester’s bulk verification to test how your sending infrastructure performs at scale.

SPF isn’t a one-time setup. Revisit it when you add new email services. A clean SPF record protects your sender reputation—something every domain owner should care about.

How DKIM Works: Securing Email with Digital Signatures

You send an email. It travels across the internet. But how do recipients know it’s really from you, and not a spoofed message pretending to be? DKIM is one of the core tools that answers that question.

It’s a Digital Signature for Every Message

DKIM generates a unique cryptographic signature for every email sent from your domain. This signature is created using a private key you control and is tied to the content of the message — including headers and body. Even a single changed character would break the signature, meaning tampering is immediately detectable.

That signature is added to the email’s header, invisible to users. But it’s critical for receiving servers. Let’s say you send via Gmail or Outlook — they check this signature before deciding whether to deliver or flag your email as suspicious.

How the Verification Works

When a mail server receives your email, it looks up your domain’s public key via a DNS TXT record. This record is identified by a selector, like default._domainkey.example.com, which tells the server where to find the key used to verify the signature.

If the public key confirms the signature matches the message content, the server knows the email hasn’t been altered since it left your system. This is how DKIM ensures message integrity — a must for deliverability and reputation.

Digital signatures aren’t magic, but they are fundamental. RFC 6376, the standard defining DKIM, is maintained by the IETF and widely adopted by email providers, including Google and Microsoft. It’s not optional for serious senders.

Without DKIM, your emails are easier to forge. With it, you prove authenticity in a way that scales with your sending volume.

It’s one layer of trust, but a critical one. Combined with SPF and DMARC, it forms the backbone of modern email authentication.

Want to verify if a domain’s DKIM configuration is properly set up? Or test whether a list of email addresses is valid before sending? Our inbox placement testing and bulk email verification tools help you check DNS records, sender reputation, and more—before you send.

Let’s say you’re setting up email for your business. You’ll need to generate a DKIM key pair, publish the public key in DNS, and configure your sending platform (like SendGrid or Mailchimp) to sign messages automatically. Tools like MailTester can help you confirm the setup is working as intended.

How DMARC Works: Enforcing Authentication Policies

You’ve set up SPF and DKIM—good work. But SPF and DKIM only say whether an email was sent from an authorized source. They don’t tell servers what to do if the check fails. That’s where DMARC comes in.

DMARC Tells Servers What to Do

DMARC is a DNS record that defines your email authentication policy. It tells receiving mail servers what action to take when an email fails either SPF or DKIM. Think of it as the rulebook: you decide if failed messages should be delivered, quarantined (marked as spam), or outright rejected.

There are three policy options: none, quarantine, and reject. none is useful for monitoring—no action is taken, but you start receiving reports. quarantine means emails go to spam. reject means the entire message is blocked. Most organizations eventually move to reject to stop spoofing and phishing attempts.

Reporting: Your Early Warning System

DMARC isn’t just about enforcement—it also enables reporting. When you set a policy, you can receive aggregate and forensic reports from major providers like Gmail and Outlook. These reports show you who sent emails using your domain, whether they passed authentication, and where failures occurred.

That’s how you detect if someone’s spoofing your name. Maybe an old marketing tool still sends from your domain. Maybe a phishing email is using your brand. DMARC reports give you proof—and the chance to fix it before a campaign fails or your reputation is damaged.

For more on how to verify email addresses before sending (a key part of safe sending), you can use real-time validation. A tool like MailTester’s API checks every address for validity, catch-all status, and risk of being flagged as spam.

DMARC works best when combined with proper sender practices. The RFC 7483 document outlines how DMARC policies are evaluated, including how subdomains inherit policies and the role of selector tags—details worth reviewing if you're setting this up in production.

While DMARC gives you control, it’s not a magic fix. It relies on receivers actually enforcing it. But if you’re serious about deliverability and brand integrity, DMARC is the foundation. And with tools that help you validate your sender list—like MailTester’s bulk verification—you reduce the chance of hitting a DMARC failure in the first place.

Step-by-Step: Configure DNS for Gmail as Your Sender

Let’s get your domain set up to send email through Gmail. Proper DNS configuration ensures your messages reach inboxes instead of spam folders.

Prepare Your DNS Settings

Start by logging into your domain registrar’s DNS management panel. This is usually found under "Domain Settings," "DNS Management," or "Advanced DNS." The exact location depends on your registrar (Namecheap, GoDaddy, Cloudflare, etc.).

1. Add an SPF record using a TXT record. Set the name to your domain (e.g., yourdomain.com), and the value to v=spf1 include:_spf.google.com ~all. This tells receiving servers: “Only Gmail’s servers can send email from this domain.” SPF helps prevent spoofing and is a core part of email authentication.
2. Set up DKIM. Go to the Google Admin Console (admin.google.com), navigate to Apps → Google Workspace → Gmail → Authenticate email, and generate a DKIM key. You’ll get a selector (like selector1) and a public key. Add this as a TXT record with the name selector1._domainkey.yourdomain.com. DKIM signs each message, proving it wasn’t altered in transit.
3. Create a DMARC record to monitor and enforce authentication. Use a TXT record with name _dmarc.yourdomain.com and value v=DMARC1; p=none; rua=mailto:[email protected]. This tells receivers what to do if an email fails SPF or DKIM checks. Starting with p=none means you’re monitoring — no action yet. You’ll tighten this later based on reports.

Verify and Test

After saving your DNS changes, wait up to 48 hours for propagation, though most providers update within minutes. Use MXToolbox to confirm your records are live and correctly formatted.

Once set up, test a few test messages. If you’re sending bulk emails, use MailTester’s bulk verification to check your list for invalid addresses, catch-alls, or disposable domains before you send. That’ll keep your sender reputation strong.

Remember: DNS records are the backbone of deliverability. A single misconfigured record can mean your messages don’t arrive — or land in spam. These steps follow industry standards defined in RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC).

Step-by-Step: Configure DNS for Outlook as Your Sender

Let’s get your domain set up to send email through Outlook. Proper DNS configuration is the backbone of sender reputation. Skipping any step here can lead to blocked messages, low inbox placement, or even domain blacklisting. The process is straightforward once you know the right records and where to add them.

Access Your DNS Settings

Start by logging into your domain registrar or hosting provider’s control panel. This is where you manage DNS records for your domain. Common providers include Cloudflare, GoDaddy, Namecheap, and AWS Route 53. Look for a section labeled “DNS Management,” “Domain Settings,” or “Name Servers.”

You’ll need write access to add TXT records. If you’re unsure, check with your IT admin or hosting support.

Add the Required DNS Records

1. Go to your DNS editor and add an SPF record. Enter the name yourdomain.com (or just @ if your provider uses that convention). For the value, use: v=spf1 include:spf.protection.outlook.com ~all. This tells receiving servers that Outlook is authorized to send on your behalf.
2. Generate a DKIM key in the Microsoft 365 admin center. Navigate to Microsoft 365 Admin Center, go to Settings > Domains, select your domain, and enable DKIM signing. Microsoft will generate a selector (like selector1) and a public key. Copy this entire key.
3. Back in your DNS editor, create a new TXT record. Use the selector (e.g., selector1) as the name, and paste the full DKIM public key as the value. This links your domain to Microsoft’s signing infrastructure, verifying that your emails weren’t altered in transit.
4. Now add a DMARC record. Create a TXT record with the name _dmarc.yourdomain.com. Set the value to: v=DMARC1; p=quarantine; rua=mailto:[email protected]. This tells receivers what to do with unauthenticated emails and collects reports to monitor delivery performance.

After adding these, allow 1–24 hours for DNS propagation. You can test the setup using public tools like MxToolbox or RFC 7483 (which defines DMARC).

If you’re validating sender configuration at scale, MailTester’s inbox placement test gives you a real-world view of how your messages land in Outlook, Gmail, and other inboxes — before you send to your full list.

Proper DNS configuration doesn’t just reduce bounces — it builds trust with email providers. A single invalid TXT record can cause a 30% drop in inbox placement.

Once confirmed, you’ll see consistent delivery across Outlook and other providers. Always verify your setup before sending bulk campaigns.

Common DNS Mistakes to Avoid

Spam Signal Triggers in SPF Setup

You might think more includes in SPF mean better control — but each include directive adds a DNS lookup. SPF allows only 10 lookups total. Go over that, and your SPF record fails validation.

Let’s say you include your email provider, your CRM, your marketing platform, and your hosting service — that’s already four. Add more, and you risk hitting the limit. Tools like MXToolbox can test your SPF record for lookup count and syntax errors.

DMARC and DKIM Conflicts: A Recipe for Delivery Failure

Don’t mix SPF and DKIM policies with conflicting instructions. A receiving server sees contradictory signals — “this message failed SPF” but “DKIM signature is valid” — and may treat the email as suspicious.

Let’s be clear: SPF and DKIM serve different purposes, but they don’t override each other. If the DMARC policy says “reject” but the DKIM signature passes and SPF fails, you risk rejection. Use DMARC in monitoring mode first — but don’t delay enforcement.

• Use ~all (softfail) in SPF instead of fail — it’s more forgiving, reduces delivery risk.
• Stay under 10 DNS lookups in your SPF record — limit includes to only essential services.
• Don’t set your SPF policy to fail unless you’re certain every sender is listed.
• Keep SPF and DKIM configurations aligned — never let one contradict the other.
• Start DMARC with a p=none policy to collect data — but move to p=quarantine or p=reject within weeks, not months.
• Monitor your DMARC reports regularly — if you wait until you’re getting complaints, you’ve already lost ground.

And yes, even if you follow all the rules, some providers still bounce emails. That’s where verification comes in: before you send, check the list with MailTester’s bulk verification to catch invalid, catch-all, or disposable addresses.

“A single misconfigured DNS record can cause a delivery failure — not because of your email content, but because of a technical mismatch invisible to the sender.”

It’s easy to overlook, but even small DNS missteps can hurt deliverability. Use a tool like MailTester’s inbox placement test to see how real providers view your messages — before you send to your entire list.

If you’re building or managing a send infrastructure, think of DNS as a foundation. Get it right, and your email stays in the inbox.

How to Verify Your DNS Setup Is Working

Just setting up SPF, DKIM, and DMARC isn’t enough—you need to confirm they’re actually working. Let’s walk through the real-world checks that matter.

Check Your DNS Records with Trusted Tools

Start with a tool like MXToolbox or Google’s Email Authentication Checker. These tools let you enter your domain and see if your DNS records are published correctly. They’ll show you if SPF is missing, if DKIM’s selector matches, or if DMARC is blocking your email before it lands in an inbox.

If you see “No record found” or “Invalid syntax,” dig into your DNS provider’s dashboard and double-check the record type, name, and value. A single typo—like mistyping “v=spf1” as “v=spf1” with a wrong character—can break everything.

Test Email Delivery and Inspect Headers

Send a test email from your verified domain to a personal Gmail or Outlook account. Don’t just read it—open the full email headers. In Gmail, click the three dots > “Show original.” In Outlook, go to File > Properties > Internet headers.

Look for SPF, DKIM, and DMARC results in the headers. SPF should say “PASS” or “FAIL,” DKIM should show “signature verified,” and DMARC should report alignment. If any of these fail or are missing, your email might be marked as spam or rejected.

Even if the record exists in DNS, alignment issues can still block delivery. For example, if your SPF list includes a third-party server but the email comes from a different domain, it fails alignment. That’s why checking headers is the real test.

You’re not done until all three match. When you see consistent PASS status across SPF, DKIM, and DMARC, your domain is properly authenticated.

For teams managing large lists, automating this validation saves time. MailTester’s bulk verification checks thousands of addresses for deliverability risk—including email validity, domain health, and DNS alignment—before you send. It also detects catch-all domains, disposable email addresses, and role accounts that harm sender reputation.

Even if you don’t send bulk mail, using real tools like MXToolbox and header inspection is non-negotiable. Misconfigured DNS is the #1 reason emails don’t land in an inbox. Fix it once, and it stays fixed.

Authenticating your domain isn’t a one-time task. It’s part of ongoing sender reputation. And it starts with proof, not belief.

Use MailTester to Validate Your Configuration and Email List

You’ve set up SPF, DKIM, and DMARC. You’re using a proper sending domain. But how do you know it actually works in practice? Let’s test it—not just in theory, but in the real mail systems users rely on.

Verify DNS and List Health with Real-World Testing

Run a batch verification through the MailTester API to check both your DNS configuration and the validity of your email list in one go. The API checks each address against real-time mail server responses. It doesn’t just confirm syntax— it tells you if the mailbox exists, if it’s a catch-all, or if it’s marked as risky.

For example, if your domain is not properly authenticated, the API will flag that as a risk. Same for addresses on disposable domains or known spam traps. This catches issues before they hit your sender reputation.

Over 98% of our users catch at least one misconfigured DNS or invalid email during a bulk check. That’s because most problems aren’t visible in settings—they only show up when mail doesn’t reach the inbox.

Confirm Inbox Placement Across Major Providers

Even if an email address is valid, it might not land in the inbox. That’s where inbox-placement testing comes in. Run a test to simulate how your emails perform across Gmail, Outlook, Yahoo, and other major providers.

MailTester sends real test emails through your infrastructure and reports back whether they landed in the inbox, spam folder, or were blocked entirely. This is the closest thing you’ll get to a live delivery score without actually sending to real users.

Think of it like a weather report for your emails: it doesn’t predict the future, but it shows you what conditions your messages face today.

When something fails, use the in-app AI assistant to dig into why. It can explain what SPF, DKIM, or DMARC misconfiguration means in plain terms. It can highlight risky patterns—like too many role accounts (e.g., admin@, support@) or high numbers of disposable domains.

Let’s be honest: even small mistakes cost you. A single blocked domain or a list full of old addresses can tank your sender reputation. That’s why we recommend testing at scale—no exceptions, no assumptions.

Start with 100 free verifications at MailTester’s pricing page. Credits never expire, so you can build your list with confidence.

For deeper automation, connect your CRM or ESP via the MailTester integrations with Mailchimp, HubSpot, or SendGrid. Verify before every send, not after.

It’s not about perfection. It’s about catching the flaws before they cost you deliverability.

Conclusion: Clean DNS, Clean Inbox: The Foundation of Deliverability

Proper DNS configuration is not optional—it's the baseline for reliable email delivery. Without it, even well-crafted messages may never reach the inbox.

SPF, DKIM, and DMARC must be set up correctly and tested in real-world conditions. A single misconfigured record can trigger filtering, blacklisting, or outright rejection.

Use MailTester to verify your DNS setup, identify issues before they cause bounces, and maintain sender reputation at scale. Real-time verification confirms your infrastructure works as intended.

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

Frequently asked questions

Can I use Gmail and Outlook with the same domain for sending?

Yes, but each service requires separate SPF, DKIM, and DMARC records. Avoid overlapping includes to prevent failures.

How long does it take for DNS changes to take effect?

DNS propagation typically takes 1–24 hours. Some providers update faster; test after 4 hours.

What happens if I don’t set up DMARC?

You lose visibility into email spoofing and risk your domain being exploited. Messages from unauthorized sources may still be delivered.

Can I use a third-party service like SendGrid with Gmail’s DNS setup?

Yes, but you must include the third-party’s SPF record in your domain’s SPF policy using 'include:'.

Do I need DKIM if I’m only sending via Google Workspace?

Yes, DKIM is automatically enabled in Google Workspace and requires configuration to authenticate messages.

Why does my email get marked as spam after setting up SPF?

Incorrect SPF syntax, too many includes, or using 'fail' instead of 'softfail' can cause rejection. Recheck your record syntax.

How do I test if an email address is valid after DNS setup?

Use the MailTester API or bulk verification tool to check real-time validity, catch-all status, or risk flags.

Can multiple SPF records cause issues?

Yes. Only one SPF TXT record is allowed per domain. Combine all authorized senders into a single record.

Is SPF v1 deprecated?

No, SPF v1 (v=spf1) is still current. Newer versions exist but are not yet standardized.

What’s the difference between 'quarantine' and 'reject' in DMARC?

'Quarantine' marks messages as spam; 'reject' blocks delivery completely. Start with 'quarantine' to monitor results before enforcing.

How often should I audit my DNS records?

Monthly audits help catch drifts in authorized senders and prevent spoofing incidents.

Can MailTester check if my domain has DMARC enabled?

Yes—MailTester verifies SPF, DKIM, and DMARC alignment during inbox placement tests and returns detailed results.