SPF DKIM DMARC Setup for AWS SES to Fix 550 5.7.15 Sender Not Authenticated

Why is your AWS SES email being rejected with 550 5.7.15 sender not authenticated?

You sent a perfectly valid email through AWS SES. It went through. Yet the recipient’s server says “550 5.7.15 sender not authenticated.” You’re not a spammer. You didn’t make a typo. So why is your email being blocked?

The answer lies in how email receivers verify who’s really sending a message. Your domain’s authentication records—SPF, DKIM, and DMARC—must match exactly what AWS SES uses. If they don’t, the email is flagged as untrusted, even if it’s legitimate. This isn’t a flaw in AWS SES. It’s a misconfiguration on your side.

Setting up SPF, DKIM, and DMARC properly isn’t optional. It’s how modern email systems prevent spoofing and protect users. Without them, your emails land in spam folders—or worse, are outright rejected. Fixing this isn’t about guessing; it’s about aligning your DNS records with AWS SES’s expected behavior.

Key takeaways

• The 550 5.7.15 error means the receiving server found no valid SPF, DKIM, or DMARC record matching your AWS SES-sent email.
• SPF, DKIM, and DMARC must be configured in your DNS and aligned with AWS SES’s sending domain and email address.
• Even if emails pass initial delivery, missing authentication causes poor inbox placement and increased spam complaints.

How SPF, DKIM, and DMARC work together to authenticate AWS SES mail

SPF, DKIM, and DMARC are the three pillars of email authentication. SPF checks if the sending IP is authorized, DKIM verifies message integrity with a cryptographic signature, and DMARC defines how receivers should handle failures—rejecting, quarantining, or allowing the email. Together, they prevent spoofing, improve inbox placement, and reduce the chance of your AWS SES emails being blocked with a 550 5.7.15 "sender not authenticated" error.

SPF: Authorizes the Sending IP

• SPF tells email providers, "These IPs are allowed to send from my domain."
• For AWS SES, you must include include:amazonses.com in your SPF record.
• If AWS SES sends from an IP not listed in your SPF, the receiving server may reject the email with a 550 error.

DKIM: Ensures Message Integrity

• DKIM signs each email with a unique cryptographic key tied to your domain.
• Receiving servers verify the signature using your public key published in DNS.
• Even a single character change in the message content breaks the DKIM signature.
• DKIM is required for AWS SES to be trusted by major inbox providers like Gmail and Outlook.

DMARC: Tells Receptors How to Respond

• DMARC builds on SPF and DKIM: it says, “If either fails, do X—reject, quarantine, or allow.”
• With DMARC set to policy=reject, a failed SPF or DKIM test results in a hard bounce.
• Use rua=mailto:[email protected] to get failure reports for troubleshooting.
• Even if you don’t yet have a strict policy, publishing a DMARC record helps improve sender reputation over time.

Together, SPF, DKIM, and DMARC create a chain of trust. They stop spoofers, signal legitimacy to ISPs, and reduce the risk of your emails landing in spam or being rejected outright. It's not optional—especially when using AWS SES. Without proper alignment, even legitimate mail gets flagged.

The SPF RFC 7208, DKIM RFC 6376, and DMARC RFC 7489 are the foundational standards you’re working with. Following these enables compatibility with all major inbox providers.

Even with correct setup, you can still face deliverability issues if your domain reputation is poor or if your recipient list contains invalid or inactive emails. Using a reliable tool like bulk email list cleaning helps ensure you're only sending to valid, engaged recipients—reducing the risk of bounces and spam complaints that hurt deliverability.

What SPF, DKIM, and DMARC records must be added for AWS SES?

Set up SPF with include:amazonses.com, publish one of AWS SES’s three DKIM TXT records using a selector like default._domainkey, and add a DMARC record with p=none to monitor delivery without blocking. Do all three to resolve the 550 5.7.15 authentication error and avoid inbox rejection.

Step-by-step setup for AWS SES authentication

1. Add the SPF record using a TXT record in your domain’s DNS: v=spf1 include:amazonses.com -all. This authorizes AWS SES to send mail on your domain’s behalf. Without it, recipients reject emails with a "550 5.7.15 sender not authenticated" error.
2. Choose a DKIM key pair from the three AWS SES provides. You’ll need three TXT records per selector. For example, if you pick default, publish these records: default._domainkey.yourdomain.com as a TXT record with a value from AWS SES, including the public key and selector.
3. Verify DKIM publishing by sending a test email from AWS SES. Check the email header for DKIM-Signature and confirm the selector matches your published record. Misconfiguration here causes 550 errors even with correct SPF.
4. Set up DMARC with a monitoring-only policy: v=DMARC1; p=none; rua=mailto:[email protected]. This helps you see delivery reports without rejecting mail. The report destination should be a real mailbox you monitor. This is an industry-standard practice (see RFC 7483).
5. Wait for propagation. DNS changes take 0–48 hours to take effect. Test again after 24 hours. Use tools like MXToolbox to check your records against real-world validation.

Why this matters for AWS SES and email deliverability

SPF, DKIM, and DMARC work together to authenticate your sender identity. AWS SES doesn’t handle this automatically — you must configure it at the DNS level. Skipping any one of them increases the chance of delivery failure, especially with Gmail, Outlook, or enterprise gateways.

SPF validates that the sending server is authorized. DKIM checks message integrity — no alteration in transit. DMARC tells receiving servers what to do if SPF or DKIM fail. Start with monitoring (p=none), test, then tighten policies once you’re confident.

Even if your DNS is correct, incorrect header alignment or missing default records will break delivery. Always verify your published DNS with real tools, not just dashboards.

After authentication is working, ensure your list quality stays high. A clean list improves sender reputation and reduces bounce rates. For high-volume senders, consider bulk email list cleaning to remove invalid or risky addresses before sending.

Common misconfigurations causing 550 5.7.15 with AWS SES

You’re seeing 550 5.7.15 sender not authenticated because your domain’s SPF, DKIM, or DMARC setup conflicts with AWS SES requirements. The most frequent culprits are multiple SPF records, mismatched DKIM selectors, overly strict SPF, or a DMARC policy set to reject before monitoring. Fixing these directly resolves the error.

SPF issues: one record, multiple mechanisms

• Only one SPF TXT record per domain is allowed. Multiple records cause validation failure. Use a single record that includes all legitimate sources, like v=spf1 include:amazonses.com ~all.
• Don't split mechanisms across multiple records. If you use third-party tools, include them with include: in one consolidated SPF record.
• Check for duplicate or conflicting records using tools like MXToolbox or the DNS lookup in your DNS provider’s console. A single SPF record must cover all sending sources.

DKIM and DMARC configuration traps

• Make sure the DKIM selector in your AWS SES configuration exactly matches the one used in your DNS TXT record. A mismatch here means DKIM fails, even if the key is correct.
• Verify the full DKIM TXT record includes the correct selector (e.g., selector1._domainkey.yourdomain.com) and the key itself. Use RFC 6376 as a reference for DKIM syntax.
• Don’t set DMARC policy to fail (p=reject) without first monitoring traffic with p=none. A single failed SPF or DKIM check will then block delivery, even if your setup is mostly correct.
• Ensure your DMARC record includes rua and ruf tags to receive alignment reports. This helps identify where authentication fails before they break sending.

You don’t need to rush to enforce DMARC. Start with monitoring. Fix failures in SPF and DKIM first, then tighten policy only after seeing no legitimate delivery issues.

Once you’ve validated your DNS records, use inbox placement testing to verify your emails reach inboxes before sending at scale.

Best practice: How to safely test SPF DKIM DMARC setup before full rollout

Before enabling strict DMARC policies, test your SPF, DKIM, and DMARC setup with a "p=none" policy. Monitor aggregate reports using tools like MXToolbox or dmarcian to catch delivery issues early. Validate DNS records, test sends to major providers, and examine email headers for alignment. This phased approach prevents inbox failures and protects sender reputation.

Start with visibility, not enforcement

1. Set your DMARC record to p=none. This tells receivers to report on authentication results without taking action. Use a tool like dmarcian or MXToolbox to collect aggregate reports. These reports show which domains are failing authentication and where delivery issues originate, including unexpected spoofing attempts.
2. Begin with a 3–7 day monitoring period. Let this phase catch any accidental misconfigurations—like a missing SPF include or a malformed DKIM signature—before enforcement. This window is standard for gathering signal before tightening policies.

Validate the setup step by step

3. Use a DNS lookup tool (like dnschecker.org or IANA’s DNS tools) to verify SPF, DKIM, and DMARC TXT records are published correctly. Check for truncation: long TXT records may be split improperly. Each record must resolve exactly as planned.
4. Send test emails to Gmail, Outlook, and Apple Mail. After receipt, check the raw headers for Authentication-Results. Look for spf=pass, dkim=pass, and dmarc=pass. A failing DMARC alignment (e.g., inconsistent domain in From: vs. DKIM) will show in the results, even if SPF and DKIM pass.
5. Adjust your SPF record to include AWS SES (e.g., include:amazonses.com) and verify it’s not exceeding 10 DNS lookups. Use RFC 7208 as reference for valid SPF syntax. Overly complex records can break authentication.
6. Once headers confirm alignment and deliverability is stable, migrate DMARC policy to p=quarantine or p=reject. This step is safe only after you’ve vetted the setup across multiple domains and received consistent pass results.

Use inbox placement testing to simulate real-world delivery and catch blacklisting risks early. Real-time email verification via API or bulk checks on your list ensures you only send to verified, deliverable addresses—avoiding spamtraps and reputation damage before you send.

SPF, DKIM, and DMARC roles compared: What each actually does

You need all three—SPF, DKIM, and DMARC—to properly authenticate email sent through AWS SES. SPF checks which IPs are allowed to send from your domain. DKIM verifies that the message content hasn’t been altered in transit. DMARC tells receiving servers what to do when SPF or DKIM fails. Skipping any one of them can trigger a 550 5.7.15 “sender not authenticated” error. Think of them as a three-tiered verification system: one for sender identity, one for message integrity, and one for enforcement.

How each protocol works in practice

Let’s break down what each actually does under the hood. SPF (Sender Policy Framework) is a DNS record that lists the authorized IP addresses allowed to send mail on behalf of your domain. Without it, receiving servers can’t verify the email came from a whitelisted source. DKIM (DomainKeys Identified Mail) adds a digital signature to each email. The receiving server checks this signature against your public key in DNS, confirming the content hasn’t been tampered with. DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top. It defines policies—such as “reject” or “quarantine”—when SPF or DKIM validation fails, and it enables reporting of authentication attempts.

Without all three properly configured, even emails from AWS SES can be blocked. Many inbox providers—including Gmail and Microsoft—require DMARC policies set to “reject” to allow high-volume sending. You can test your setup with tools like MxToolbox or SparkPost’s DMARC guide. If any component fails, the receiving server may return a 550 5.7.15 error. You can’t rely on just SPF or DKIM alone. The full stack is required for deliverability at scale.

For teams sending at scale, verifying the authenticity of your domain is just the first step. You also need to ensure your email list is clean. Use bulk list cleaning to remove invalid, disposable, or malformed addresses before sending—so even with perfect SPF/DKIM/DMARC, you don’t waste sends on addresses that will never receive.

How to validate your AWS SES setup is fully functional

You can confirm your SPF, DKIM, and DMARC setup for AWS SES is working by sending a test email to a personal Gmail or Outlook inbox, then checking the full message headers. Look for Authentication-Results: spf=pass dkim=pass dmarc=pass in the source — if any field shows fail or neutral, your authentication is misconfigured and could trigger a 550 5.7.15 error. Use the raw headers to debug and fix.

Step-by-step verification process

1. Send a test email through AWS SES to a personal Gmail or Outlook address. Use a real, verified email from your domain and a clean message body. This ensures the full authentication pipeline runs.
2. Open the message in the recipient inbox and click on "Show original" (in Gmail) or "View message source" (in Outlook). This reveals the raw email headers, where authentication results are recorded.
3. Locate the Authentication-Results header near the top of the source. It lists whether SPF, DKIM, and DMARC passed. Look for spf=pass, dkim=pass, and dmarc=pass. These are the signals that your domain is properly authenticated.
4. If any field shows fail or neutral, review your DNS records. A common issue is a missing or incorrect SPF include directive, a DKIM selector mismatch, or a DMARC policy with p=reject but no reporting set up.
5. Use a public DNS lookup tool like MXToolbox or MxToolbox to validate your DNS records in real time. These tools reflect the latest state and can catch syntax issues your provider might miss.

What to do if verification fails

If your test email doesn’t show all passes, one of three things is likely wrong: your SPF record isn’t inclusive of AWS SES IPs, your DKIM signature isn’t being added by SES, or your DMARC policy isn’t aligned with your SPF and DKIM setup. AWS SES generates DKIM keys for each region — make sure you've added the correct selector and public key to your domain’s DNS.

According to RFC 7001, DMARC alignment requires either domain or SPF, and domain or DKIM to match the From domain. Misalignment causes rejection even if SPF and DKIM pass individually. You can test alignment using RFC 7001 principles and tools like dmarcian.com’s DMARC analyzer.

If you're sending high-volume campaigns and see inconsistent results, consider verifying your list first. Use bulk email list cleaning to remove invalid or risky addresses before sending — this helps avoid sender reputation issues that compound authentication failures.

Why email list hygiene matters for inbox placement, even with correct SPF DKIM DMARC

You can have perfect SPF, DKIM, and DMARC set up for AWS SES, but if your list includes invalid, role-based, or disposable email addresses, your sending will still fail—high bounce rates hurt your sender reputation, trigger throttling, and can lead to blocklisting, even with valid authentication.

Bounces don’t just vanish—they hurt your sender score

Even with correct authentication, sending to an email that doesn’t exist, is a role account like [email protected], or is from a disposable domain (like mailinator.com) results in a hard bounce. These bounces are a direct signal to inbox providers that your list isn’t well-managed.

Providers like Gmail and Outlook monitor your bounce rate over time. A sustained rate above 0.1% can trigger warnings. If it climbs higher, your messages may be quarantined or blocked entirely, regardless of your technical setup. This is why authentication alone isn’t enough.

Mailchimp, HubSpot, Klaviyo—your tools don’t catch bad addresses automatically

Most marketing platforms let you send and track opens, but they don’t validate email addresses in real time. They treat [email protected] the same as [email protected] until delivery fails. That’s a problem.

It’s not just invalid addresses—the real danger is role-based emails (like sales@, info@) and addresses from disposable domains. These are common red flags in inbox placement reports from tools like Return Path and Mail-Tester. The more you send to them, the lower your score.

Let’s be clear: fixing authentication is step one. But if your list is full of low-quality addresses, even the best DKIM signature won’t save you.

Email List Validation can help. Its bulk verification feature checks for invalid, role, disposable, and catch-all emails in advance. It reduces bounce rates before you send. You can test with up to 100 free verifications at no risk.

For real-time validation, the API integration lets you clean addresses as they enter your system—ideal for forms, sign-ups, or CRM syncs.

Even with flawless technical setup, your sender reputation depends on the quality of your list. Clean data isn’t optional—it’s part of deliverability.

Use Email List Validation to clean and verify your list before AWS SES sends

Run your mailing list through Email List Validation’s bulk verification to catch invalid emails, catch-all domains, and disposable addresses before sending via AWS SES. This prevents 550 5.7.15 sender not authenticated errors caused by poor list hygiene and protects your sender reputation. You’ll send only to valid, engaged inboxes.

1. Upload your list to the bulk verification tool. Use https://emaillistvalidation.com/bulk-email-list-cleaning to scan thousands of addresses in minutes. The tool checks syntax, domain existence, mailbox responsiveness, and flags risky patterns like throwaway domains or role-based emails.
2. Review and filter out invalid or high-risk entries. The results include clear verdicts: valid, invalid, catch-all, or risky. Remove or suppress non-deliverable addresses that could trigger spam traps or bounce rates above 5%.
3. Use the real-time API for automatic validation in your workflow. Integrate the https://emaillistvalidation.com/real-time-email-verification-api into your signup forms or CRM to validate new addresses as they’re added. With 98.9% accuracy, it helps maintain low bounce rates and avoids hitting sender limits on AWS SES.
4. Connect with Mailchimp, HubSpot, Klaviyo, or SendGrid. Use the integrations to automate clean-up before every campaign. This reduces manual effort and maintains list health without interrupting workflows.
5. Start with 100 free verifications. Test the system risk-free. Unused credits never expire — you can build your list over time without losing value. This low barrier lets you validate high-volume lists without upfront cost.

Why this reduces 550 5.7.15 errors

Amazon SES enforces sender reputation through strict bounce and complaint thresholds. Sending to invalid or non-responsive addresses increases bounce rates, which can trigger 550 5.7.15 errors — even when SPF, DKIM, and DMARC are properly configured.

According to RFC 7054, consistent authentication isn’t enough if your list contains outdated or malformed addresses. A clean, validated list reduces infrastructure load and prevents reputation damage that can block emails across multiple providers.

Many providers, including ZeroBounce and NeverBounce, use similar verification techniques — but not all integrate directly with marketing platforms or support real-time checks. Email List Validation’s accuracy and ease of automation make it a reliable complement to AWS SES.

Before you send bulk campaigns, verify that every address on your list is reachable. This step doesn’t replace proper SPF, DKIM, and DMARC setup — but without it, those measures won’t matter. A clean list is the foundation of deliverability.

You still get 550 5.7.15? Double-check your DNS propagation and TTL

If you're still seeing 550 5.7.15 after setting up SPF, DKIM, and DMARC for AWS SES, your DNS changes haven’t fully propagated yet. This can take up to 48 hours globally. Even after updating your records, they might not be visible worldwide until then. Let’s make sure you’re not missing a step.

Check DNS propagation before assuming the setup failed

• Use dig or nslookup from multiple global locations to check if your records are visible worldwide.
• Verify SPF, DKIM, and DMARC records using free online tools like MxToolbox or DNSChecker.org.
• Check from a non-local network — home internet can cache old DNS responses for hours.
• Run a test from AWS SES’s own sending domain if possible; it will show the actual DNS state as seen by Amazon’s infrastructure.

Reduce propagation time with proper TTL planning

• Lower your DNS record TTL to 300 seconds (5 minutes) at least 24–48 hours before making changes.
• If you changed your records without adjusting TTL first, expect delays in propagation, even after update.
• Check your domain’s SOA (Start of Authority) record — it contains the refresh and minimum TTL values that control how often resolvers recheck your records.
• A high SOA minimum TTL (e.g., 86400 seconds) means changes can take days to reflect, even if your DNS provider updates instantly.

Propagation isn’t a one-time event. It's a network-wide synchronization process governed by DNS standards outlined in RFC 1035. Your DNS server’s ability to report changes is only part of the picture.

You don’t need a miracle to fix 550 5.7.15. You just need to confirm the records are seen—and seen correctly—by major email providers. Double-check your TTL, use trusted DNS lookup tools, and verify across geographies before blaming AWS SES.

Final step: monitor email deliverability after authentication setup

Authentication with SPF, DKIM, and DMARC is only effective if your emails consistently reach inboxes. Use inbox placement tests to confirm delivery over time, as test results reflect real-world filtering behavior across major providers.

Monitor key health signals

• Track sender reputation using tools like SenderScore or Google Postmaster Tools to detect early signs of trust degradation.
• Enable DMARC reporting to collect data on authentication attempts and identify misconfigurations before they cause bounces or rejections.
• Verify all new email list entries with Email List Validation to prevent invalid or risky addresses from harming your sender reputation.

Deliverability isn’t a one-time fix. Continuous validation and monitoring ensure your AWS SES setup remains trusted and your messages remain visible in inboxes.

Keep reading

• Bounce management: hard bounces, soft bounces and bounce rate (complete guide)
• How ESPs Use Machine Learning to Classify 550 5.7.11 Phishing Detection in Real Time
• Automated Re-Engagement Campaigns for 550 5.1.1 Bounce-Prone Lists
• Automated Re-Engagement After 550 5.1.1 SMTP Error with Real-Time Bounce Analysis
• Mailgun 550 5.7.16 Content Filter Timeout Error Inbound Troubleshooting

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

Frequently asked questions

What does error 550 5.7.15 mean?

This error means the receiving mail server rejected the email because it failed sender authentication checks — typically due to missing or incorrect SPF, DKIM, or DMARC records.

Can I use multiple SPF records?

No. Only one SPF TXT record is allowed per domain. Combine all mechanisms into a single record using 'include:' statements.

Does AWS SES require DKIM for delivery?

DKIM is not required but strongly recommended. Without it, your emails may be flagged as suspicious, especially by major inboxes like Gmail or Outlook.

How long does DNS propagation take?

DNS changes typically take 1–48 hours to propagate worldwide. Use tools like MXToolbox to confirm visibility.

Why do I still get rejected after setting up SPF DKIM DMARC?

Common causes include incorrect record syntax, multiple SPF records, delayed DNS propagation, or DMARC policies set to 'reject' before monitoring.

Can Email List Validation help with deliverability issues?

Yes. It improves deliverability by removing invalid, disposable, and role addresses before sending — reducing bounces and improving sender reputation.

What is a catch-all email address and why is it risky?

A catch-all accepts all emails sent to a domain, even invalid addresses. It increases spam exposure and can lead to reputational harm.

Do DMARC reports help prevent future rejections?

Yes. DMARC aggregate reports identify sources of failed authentication, allowing you to correct issues before they affect delivery.

What’s the difference between SPF, DKIM, and DMARC?

SPF checks sending IPs, DKIM verifies message integrity, and DMARC sets policies for handling failed authentication — they work together to prevent email spoofing.

Can I use Email List Validation with AWS SES?

Yes. The tool integrates with major platforms like Mailchimp and SendGrid and can clean lists before sending via AWS SES, reducing delivery failure risk.