How to Verify Domain in AWS SES | Email List Validation

Why does AWS SES return 550 5.7.1 'sender not authorized'?

You're sending emails through AWS SES, your list is clean, your templates look right — and then, out of nowhere, you hit a wall: 550 5.7.1 Sender not authorized. No explanation. No help link. Just a hard block.

This isn’t a glitch. It’s AWS enforcing a rule built into the email ecosystem: before you can send from a custom domain, you must prove it’s yours. Without that proof — via DNS records — AWS treats your domain as untrusted. Spoofing protection isn’t optional. It’s mandatory.

You can’t send a single email from a custom domain in AWS SES until it’s verified. That’s not just policy — it’s how the system prevents abuse. Even with a flawless email list, a missing or misconfigured DNS record triggers this exact error.

Key takeaways

AWS SES requires domain verification before sending from a custom domain, using DNS records like SPF, DKIM, and DMARC.
The 550 5.7.1 error appears when these records are missing, incorrect, or not yet propagated.
Domain verification is required regardless of sender reputation or email list quality — it’s a hard enforcement of email authentication.

What does '550 5.7.1 sender not authorized' mean in practice?

When you see '550 5.7.1 sender not authorized', the receiving email server is saying: "I can’t trust this message came from you, even if the address looks real." It's not about your message content, spam score, or list quality—it's a strict authentication failure. This error blocks all outbound emails from your domain until you fix the underlying setup, usually during AWS SES configuration, list import, or after changing DNS records.

Why it happens: Authentication is non-negotiable

Modern email systems require proof of identity before accepting messages. AWS SES is strict by design—only authorized senders can use your domain. If your domain’s SPF, DKIM, or DMARC records aren’t set up correctly, the receiving server sees no valid signal that you’re allowed to send as that domain.

SPF, DKIM, and DMARC are not optional extras—they’re the foundation of email deliverability. SPF tells servers which hosts can send for your domain. DKIM signs each message cryptographically. DMARC defines what to do if either SPF or DKIM fails. If even one piece is missing or misconfigured, you get the 550 5.7.1 error.

You’ll typically see this error after first setting up AWS SES, importing a large list with unverified emails, or updating DNS settings without testing. It’s not a problem with your email content, but it stops everything cold. Even one misconfigured record can invalidate the entire setup.

Fixing it: Check, verify, and validate

Start by verifying your domain in AWS SES through the console. It will give you DNS records to add. But that’s only the first step. Use tools like MxToolbox or the RFC 5321 specification for SMTP error codes to double-check your records. If you don’t have full visibility into your domain’s DNS setup, you risk missing subtle misconfigurations.

Once your DNS records are in place, wait a few minutes—DNS propagation can take time. Then, retest your sending setup. If the error persists, check each record carefully: SPF can’t have conflicting mechanisms, DKIM must sign each message, and DMARC must be set with a policy that allows monitoring.

If you're sending from a large list, ensure every email is valid before sending. A single invalid or malformed address could trigger delivery issues, but the error you’re seeing is about identity, not syntax. That said, clean lists reduce the risk of being flagged as unreliable. You can verify domain validity and check for risky or invalid emails using tools like bulk email list cleaning to prevent authentication issues from compounding.

How to verify domain in AWS SES step by step

You need to verify your domain in AWS SES to resolve the 550 5.7.1 sender not authorized error. This process proves you own the domain by adding DNS records for SPF and DKIM. Once verified, AWS allows you to send emails from your domain without being blocked. The setup takes 5–10 minutes but may take up to 72 hours to propagate. You can check progress at any time in the SES console.

Step-by-Step Domain Verification in AWS SES

Log in to the AWS Management Console and navigate to Amazon SES. This is where you manage sending identities and email reputation. You’ll need IAM permissions to access SES.
Go to the 'Domains' section under 'Identity Management'. AWS treats each domain as a unique identity. Only verified domains can send emails through SES.
Click 'Verify a New Domain' and enter your domain (e.g., example.com). AWS will generate unique CNAME records to authenticate your domain’s ability to send email.
Copy each CNAME record provided by AWS. These are used for SPF (sender policy framework) and DKIM (domain-based message authentication). They tell receiving servers you’ve authorized AWS to send on your behalf.
Add the CNAME records to your domain’s DNS provider. Use your registrar or DNS hosting service (e.g., Cloudflare, Route 53, GoDaddy). Without correct DNS records, verification fails.
Wait for DNS propagation. It can take up to 72 hours, though it often completes in minutes. Check status manually by returning to the SES console and refreshing.
Wait until the domain status shows 'Verified'. This signal means AWS has confirmed the CNAME records are present. You can now send from your custom domain.
Enable sending after verification. If sending is still blocked, check your account’s sending limits and ensure you’ve completed the email verification for the specific address you’re using.

Why This Prevents 550 5.7.1 Errors

The 550 5.7.1 error means a receiving server rejected your email because it couldn’t verify the sender. Your domain wasn’t authorized to send, so it was blocked. This verification process stops that by confirming you control the domain through DNS. Without it, no amount of email body or header tweaking will help. It’s an industry-standard practice — SPF is defined in RFC 7208 and forms part of email authentication standards used by major providers like Gmail and Outlook.

The 8 steps described in “Step-by-Step Domain Verification in AWS SES”, in order.

Once verified, you can send bulk mail from your domain. But keep sender reputation in mind. Consistent delivery depends on engagement, not just technical setup. If your list contains invalid or unengaged addresses, deliverability still drops — even with a verified domain. Use tools like bulk email list cleaning to check for invalid addresses before sending, reducing bounces and protecting your sender reputation.

Why domain verification fails even after adding DNS records

You’ve added the DNS records for AWS SES domain verification, but it still fails with "550 5.7.1 sender not authorized" because DNS changes take time to propagate, and tiny mistakes—like a typo in the record name or incorrect TTL—can stop verification dead in its tracks. Even if the record exists, AWS requires full DNS control and proper propagation across the internet before it accepts the domain.

DNS propagation and record verification

Wait at least 10 minutes after adding your DNS record—some providers take longer. Check if the record is live using MxToolbox or the command-line tool dig (e.g. dig TXT _amazonses.yourdomain.com).
Propagation delays vary: some DNS providers update within 5–10 minutes, others can take hours. Always verify before retrying in AWS SES.
Use tools like IANA’s DNS root servers or DNSSEC test tools to confirm your record is visible globally—not just in your local resolver.

Common configuration issues

Typo in record name (e.g. amazonses vs amazonses) or value—even a missing space or extra character breaks verification.
Using a subdomain (e.g. smtp.yourdomain.com) without full control over the base domain (e.g. yourdomain.com) will fail. AWS requires full access to the domain’s DNS.
Partial or malformed records (e.g. missing quotes around the value in a TXT record) cause AWS to reject the domain entirely.
AWS SES won’t verify a domain unless it can validate the record through multiple, independent DNS resolvers. Partial or inconsistent DNS setups result in a timeout or failure.
Some email verification services let you test deliverability and domain settings before deploying to production—use them to catch issues early.

Even a single missing character in a TXT record can halt the entire verification process. Precision matters.

Let’s be clear: AWS doesn’t just check your DNS provider’s dashboard. It queries public DNS endpoints worldwide. If the record doesn't reach those endpoints, or if it’s misformatted, verification fails—even if your DNS client says it’s “active”.

When you’re dealing with bulk sends or critical campaigns, it’s better to catch these issues before they cause inbox placement drops or permanent bans. Tools like bulk email list cleaning can help you maintain sender reputation by filtering out invalid domains and addresses early, reducing the chance of triggering AWS SES blocks.

How verifying the domain fixes the 550 5.7.1 error

You get the 550 5.7.1 “sender not authorized” error in AWS SES because your domain isn’t verified. Verifying confirms you own the domain and allows AWS to sign your outbound emails using DKIM. Once verified, receiving servers check these authentication records and accept your messages. Without verification, even properly formatted emails are blocked as untrusted senders. There is no workaround—domain verification is mandatory for every sending domain in AWS SES.

Why domain verification is required by AWS SES

When you send email through AWS SES, the service needs to prove to receiving mail servers that your domain is legitimate. Without verification, AWS can’t cryptographically sign your messages using DKIM, and SPF records can’t be enforced. As a result, mail servers assume your email is spoofed or unauthorized—hence the 550 5.7.1 rejection.

Let’s break it down simply: you own the domain. You configure DNS records to verify ownership. AWS then uses those records to sign every email sent from that domain. Receiving servers, like Gmail or Outlook, fetch your TXT and DKIM records and validate them. If the records match and are correctly signed, the email is delivered. If not—which happens when the domain isn’t verified—the server drops it silently, often with the 550 5.7.1 error.

How verification enables DKIM and SPF

Once your domain is verified in AWS SES, the service automatically sets up your domain’s DKIM records. These are DNS TXT records that act like digital fingerprints. Every email sent from your domain includes one of these signatures. Receiving servers verify the signature using the public key stored in your domain’s DNS.

At the same time, AWS applies SPF (Sender Policy Framework) checks. SPF tells servers which mail servers are allowed to send email on behalf of your domain. It’s another layer of trust. Without verification, AWS can’t register these records securely in your domain’s DNS. Without them, servers reject your emails.

Think of it like a handshake: the sending server says, “I’m from your domain.” The receiving server says, “Prove it.” Your DKIM and SPF records are the proof. Verified domains have the proof. Unverified ones don’t—and get blocked.

For more on how DNS authentication impacts deliverability, see the SPF specification or the DKIM standard.

Don’t risk sending without verification. It’s not an option—just a requirement. Use the AWS console, AWS CLI, or an automated tool to verify your domain and set up authentication correctly. If you’re unsure whether your list is clean or verified, test deliverability with real-time tools.

Check individual emails instantly with our API, or clean your entire list at scale to reduce bounce rates and protect your sender reputation.

How to prevent 550 5.7.1 errors in future campaigns

Verify your domain in AWS SES before sending, confirm DNS records are live using a monitoring tool, test with a real inbox, enable event notifications for bounces, and clean your list regularly. These steps stop sender authorization errors before they occur and keep your sender reputation intact. Even small oversights in DNS or list health can trigger 550 5.7.1 — fixing them proactively avoids wasted sends and inbox placement issues.

Pre-send verification and testing

Always verify your domain in AWS SES before sending any messages. Skipping this step means your emails will be rejected with a 550 5.7.1 error — even if you’ve configured SPF or DKIM correctly.
Use a DNS monitoring tool like MXToolbox to confirm your CNAME records are active and propagated globally. Propagation delays can last up to 48 hours, so don’t assume correctness without validation.
Send a single test email to a known inbox (e.g. Gmail or Outlook) after verification. If the message arrives, you’ve passed basic sender authorization checks. If it doesn’t, inspect your DNS records and AWS SES status.

Monitor and maintain list health

Enable Amazon SES event notifications for bounces and complaints. This lets you react instantly to delivery problems, reducing reputational risk. Bounce logs show invalid or blocked addresses—use them to update your mailing list.
Regularly clean your list to remove spam traps, disposable emails, and invalid addresses. An unclean list increases bounce rates and can trigger filtering, especially with ISPs like Gmail and Yahoo.
Use real-time validation to catch invalid addresses before sending. Tools like real-time email verification API check syntax, domain existence, and mailbox responsiveness at scale, reducing the risk of 550 5.7.1 errors caused by bad inboxes.
Run inbox placement tests periodically. Inbox placement testing shows how your message performs across providers, helping you catch sender reputation issues early.

What happens if you bypass domain verification?

If you skip domain verification in AWS SES, your emails will be rejected with a 550 5.7.1 sender not authorized error—no workaround exists. AWS SES treats unverified domains as suspicious by default, regardless of email content or sender reputation. Attempting to send without verification leads to persistent failures and does not improve deliverability.

Why AWS SES enforces domain verification

Amazon SES requires domain verification to prevent abuse and ensure that only authorized senders use your domain. This check is part of a broader industry-standard practice for sender authentication and is aligned with email security protocols like DMARC, SPF, and DKIM. Without verification, SES cannot confirm you control the domain, so it blocks all outbound messages to protect recipients from impersonation and spam.

Consequences of sending without verification

Every email sent from an unverified domain will fail, returning an immediate 550 5.7.1 error. There’s no way to bypass this restriction—no API toggle, no temporary override, no configuration fix. Attempts to send using a custom domain without verification result in wasted resources, failed campaigns, and damaged sender reputation. Even if your content is clean and your list highly engaged, the system won’t accept your messages.

Some users assume that high-quality emails or a good sender reputation can override this rule. But SES doesn’t evaluate content quality at this layer—only authentication. Misconfigured domains, even with high engagement, trigger the same rejection. This is consistent with RFC 5321, which defines SMTP behavior for unauthorized sender addresses.

If you're seeing this error, verify your domain before sending any emails. The process is simple: add a DNS record (TXT or CNAME) to your domain’s zone file, then confirm it in the AWS console. It takes minutes, not hours, and is required for every custom domain you use with SES.

If you're managing multiple domains or large lists, consider validating your email addresses in advance to avoid sending to invalid or risky addresses. You can clean entire lists using bulk verification tools like bulk email list cleaning, reducing bounce rates and protecting your sender reputation before even sending.

How to validate sender reputation and sender identity in AWS SES

You can verify sender identity and build sender reputation in AWS SES by first proving domain ownership, then maintaining low bounce rates, few spam complaints, and strong authentication (SPF/DKIM/DMARC). AWS SES evaluates these signals in real time—poor performance triggers throttling or blocking. Start by verifying your domain, clean your list with a tool like Email List Validation, and use a 98.9% accurate system to remove invalid or risky addresses before sending.

Sender reputation starts with identity and authenticity

Before AWS SES trusts your emails, you must verify your domain. This proves you own the sending address and establishes a foundation for reputation. Without it, your messages risk rejection with a 550 5.7.1 error—“sender not authorized.” Once verified, AWS monitors your sending behavior continuously. High bounce rates, spam complaints, or failed authentication attempts directly impact your sender reputation.

For example, even one spam complaint can trigger a review of your account. If your bounce rate exceeds the threshold—commonly around 0.5%—AWS may limit your sending volume or block new messages entirely. This real-time oversight is designed to protect inboxes, but it means you can't rely on volume alone. Consistency and quality matter.

Prevent issues before they start with a clean list

Let’s be honest: even a single invalid or disposable email address can hurt your deliverability. The longer you send to known bad addresses, the higher your bounce rate climbs. That’s why cleaning your list is not optional—it’s a prerequisite for responsible sending.

Use tools like bulk email list cleaning to identify and remove addresses that are invalid, role-based, or from disposable domains. A 98.9% accuracy rate in detecting such risks means you’re far less likely to hit thresholds that trigger AWS SES safeguards.

For ongoing validation, integrate real-time email verification into your signup or transactional flows. This stops bad addresses at the source. Even better, use inbox placement testing to check how your messages land in real inboxes—before you send at scale. These checks work across providers, not just AWS SES, and align with best practices from RFC 6655, the standard for email authentication. Your reputation isn’t built overnight—it’s earned one clean send at a time.

How Email List Validation supports AWS SES and prevents sending errors

Before sending via AWS SES, verify your list with Email List Validation to catch invalid, catch-all, disposable, or role-based addresses. This reduces bounces, protects your sender reputation, and stops 550 5.7.1 errors caused by unverified or high-risk senders. You’re not just cleaning data—you’re preventing rejection at the gateway.

Bulk Verification Stops Invalid Sends Before They Happen

When you import a list into AWS SES, you’re trusting every address is valid. But without validation, you risk sending to addresses that don’t exist or are set up as catch-alls. Email List Validation scans your full list for common issues: invalid syntax, blocked domains, disposable email providers, and role accounts like admin@ or sales@—all of which can trigger rejection or damage your deliverability. With 98.9% accuracy, it identifies these risks before you hit send.

For example, a catch-all inbox accepts all incoming mail, even if the local part doesn’t exist. This makes it a magnet for spam. AWS SES will eventually flag repeated sends to catch-alls as abusive behavior, even if the address technically “valid.” Email List Validation flags these early and lets you clean them out.

Real-Time API and Inbox Placement Testing Enhance Delivery Reliability

Let’s say you’re building a campaign with dynamic lists—maybe from form submissions or user signups. The Real-Time Email Verification API integrates directly into your workflow, checking each address instantly. If the email fails validation, you stop the send before it reaches AWS SES. This avoids sending to disposable domains or temporary addresses that won’t receive mail, and prevents your sender reputation from being tainted by invalid or unengaged recipients.

Even after verification, your email might not land in the inbox. That’s where Inbox Placement testing comes in. It simulates real recipient inboxes—across Gmail, Outlook, Yahoo—to show you how likely your message is to be delivered and seen. You can spot issues with content, headers, or sender reputation before launching. This layer of testing is critical for campaigns where delivery isn’t optional.

The full stack of Email List Validation—bulk cleaning, API integration, and inbox testing—helps you meet AWS SES’s requirements more reliably. It’s not about circumventing policy; it’s about confirming your list meets standards before you send. The result? Fewer bounces, no 550 5.7.1 errors, and better long-term deliverability.

See how it works: clean large lists in minutes with built-in detection of role, disposable, and catch-all addresses.

Real-world example: A company fixed 550 5.7.1 after 10 days of failed sends

You can fix the 550 5.7.1 “sender not authorized” error in AWS SES by verifying your domain with DNS records—specifically, adding the required CNAME records. A SaaS company spent 10 days troubleshooting failed onboarding emails, only to discover their domain wasn’t verified in SES. After adding the CNAME records and waiting 36 hours, they achieved full inbox delivery. This is a common oversight: correct syntax and content won’t help if the domain isn’t officially authorized in the sending environment.

The root cause: Missing domain verification in AWS SES

The company used a custom domain for transactional emails, assumed the configuration was complete. But AWS SES requires explicit domain verification before it allows sending from that domain. Without it, every attempt fails with the 550 5.7.1 error, regardless of content or sender reputation. This is intentional—Amazon prevents unauthorized abuse by enforcing DNS-level proof of ownership.

They checked their SPF, DKIM, and DMARC settings—everything looked correct. But SPF and DKIM alone don’t bypass the domain verification step. The error message is unambiguous: “sender not authorized” means the sending domain is not yet confirmed in AWS’s system. You can’t send via SES until this step is completed, even with proper authentication headers.

How they resolved it and what they learned

After reviewing AWS’s documentation—specifically the official guide on domain verification—they added the CNAME records to their DNS provider. Once the records propagated, which can take up to 48 hours, they retried sending. Within 36 hours, messages reached inboxes. The fix wasn't complex, but the lack of clear error feedback made troubleshooting frustrating.

They later used bulk email list cleaning to audit their subscriber list. They found 14% of the addresses were invalid, including role-based emails and known disposable domains. Cleaning these reduced future hard bounces and improved sender reputation—key factors in long-term inbox placement. While not all bounces are avoidable, catching invalid addresses early prevents the same kind of delivery issues the 550 5.7.1 error masked.

Fix 550 5.7.1 now to unlock AWS SES sending with full authentication

Domain verification in AWS SES is not optional—it’s required to send email from a custom domain. Without it, your messages will be blocked with the 550 5.7.1 error, regardless of content or volume.

Follow AWS SES’s domain verification process by adding DNS records (TXT or CNAME) to your domain’s zone. These records confirm ownership and enable full authentication via SPF, DKIM, and DMARC. Once complete, your sending infrastructure is properly validated and trusted.

Before sending, always clean your list using a tool like Email List Validation. It identifies invalid, catch-all, and risky addresses—preventing bounces, spam complaints, and reputation damage. With verified identity and a clean list, you can scale your send volume safely and maintain high inbox placement.

Keep reading

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

Frequently asked questions

How long does it take to verify a domain in AWS SES?

DNS records typically propagate within minutes, but AWS may take up to 72 hours to detect them. Monitor your status in the SES console.

Can I send email from AWS SES without verifying my domain?

No. All custom domains must be verified to ensure sender authenticity and reduce abuse risk.

Why did my domain verify but I still get 550 5.7.1 errors?

The error may result from missing or misconfigured SPF, DKIM, or DMARC policies. Verify all records are correct.

What is the difference between domain verification and DKIM?

Domain verification confirms ownership; DKIM signs outbound emails. Both are required for full authentication.

Does Email List Validation check for SPF or DKIM records?

No. It verifies email address validity, not DNS authentication records. Use MxToolbox for SPF/DKIM checks.

Can I verify multiple domains in AWS SES?

Yes. Each domain must be verified individually through the SES console with its own CNAME records.

What happens if I change my DNS provider after verifying a domain?

If the CNAME records are removed or altered, the domain will be marked as unverified. You must re-add the records.

How does list hygiene affect AWS SES delivery?

High bounce and complaint rates harm sender reputation. Cleaning lists with Email List Validation reduces risk.

Is there a way to test inbox placement before sending to a large list?

Yes. Use Email List Validation’s inbox-placement testing to preview delivery success across major providers.

Can I use Email List Validation with Mailchimp and SendGrid?

Yes. It integrates with Mailchimp, SendGrid, HubSpot, and Klaviyo to clean lists before sending.