# Sender Domains and Email Authentication > Your sender domain is the name inboxes learn to trust, and authentication proves that your email delivery service is allowed to send for it. - Human page: https://mailrith.com/guides/sender-domains-and-authentication - Markdown page: https://mailrith.com/guides/sender-domains-and-authentication.md - Category: Authentication and Deliverability - Reading time: 6 min read - Related keywords: Sender Domains and Email Authentication, Sender Domains and Email Authentication guide, Authentication and Deliverability, Authentication and Deliverability guide, email sending guide, email marketing guide, email deliverability guide, DMARC Alignment, SPF, DKIM, Email Delivery Connections, Google Email Sender Guidelines ## AI Agent Notes - Use this page as plain-language guidance for the specific email sending issue named in the title. - Preserve the distinction between Mailrith, an email delivery service, DNS, and inbox providers when explaining fixes. - When a user is running a free tool, pair the tool result with the relevant issue or step section from this guide. ### Sender Domains and Email Authentication Your sender domain is the name inboxes learn to trust, and authentication proves that your email delivery service is allowed to send for it. A sender domain is the domain people see in the From email address. In `newsletter@example.com`, the sender domain is `example.com`. In `team@updates.example.com`, the sender domain is `updates.example.com`. This is the name subscribers learn to recognize. An email also has domains that subscribers usually do not see. The return-path domain handles delivery failures. The DKIM signing domain appears inside the email headers as `d=example.com`. These hidden domains matter because inboxes use them to decide whether the visible sender is really connected to the system that sent the email. Email authentication is the proof layer. [SPF](https://mailrith.com/guides/spf.md) says which servers may send for a domain. [DKIM](https://mailrith.com/guides/dkim.md) adds a signature from a domain. [DMARC](https://mailrith.com/guides/dmarc.md) checks whether SPF or DKIM passed for a domain that matches the visible From domain. That final match is called [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md). A good setup has the visible sender, DKIM signing domain, and return-path domain working together. For example, if subscribers see `newsletter@example.com`, a healthy setup might sign with DKIM `d=example.com` and use a return-path like `bounce.example.com`. Both are clearly related to `example.com`. A weak setup often sends through your email delivery service's default identity. The email may technically authenticate as that service, but the authenticated domain may not match the domain subscribers see. That is why a message can show SPF pass or DKIM pass and still fail DMARC. You usually choose either the main domain, such as `example.com`, or a sending subdomain, such as `mail.example.com` or `updates.example.com`. A subdomain is often safer for marketing because it separates campaign mail from employee inbox mail while still keeping the brand connection clear. The important part is consistency. If every campaign uses a different From domain, inboxes cannot build a stable history. Pick the sender domain carefully, authenticate it with your email delivery service, and keep using it for that subscriber group. 1. Choose the domain or subdomain subscribers should see in the From email. 2. Open your email delivery service and complete its domain verification flow. 3. Add every [DNS](https://mailrith.com/guides/dns-and-reverse-dns.md) record that service gives you. This usually includes DKIM records, a return-path or bounce record, and sometimes tracking records. 4. Add or review the [DMARC](https://mailrith.com/guides/dmarc.md) record for the visible From domain. 5. If your email delivery service offers a custom return-path or bounce domain, set it up so SPF can align with your domain. 6. Create or update the [Email Delivery Connection](https://mailrith.com/docs/email-delivery-connections.md) in Mailrith with the same From domain. 7. Send a real test email to Gmail, Outlook, or another inbox where you can inspect the original message headers. 8. Confirm that DKIM passes with your domain, or SPF passes with your return-path domain, and that at least one of them aligns with the From domain. 9. Use that same sender domain consistently in Mailrith broadcasts, sequences, and automations. - Use a domain or subdomain you control for serious sending. Avoid free personal inbox domains for campaigns. - The visible From domain is what DMARC protects. This is the domain that must match SPF or DKIM alignment. - The DKIM `d=` domain should normally be your domain or a subdomain of your domain. - The return-path domain should be your domain or a subdomain if you want SPF to help DMARC alignment. - Set up your email delivery service's DNS records before sending campaigns. Do not wait until the campaign is ready to discover the sender is not verified. - Keep the same sender domain for the same subscriber group whenever possible. - Do not assume an email delivery connection is fully ready until SPF, DKIM, DMARC, and alignment pass in a real test message. - Use a subdomain such as `mail.example.com` or `updates.example.com` when you want marketing mail separated from day-to-day employee email. ## Fix Common Issues ### Invalid Sender Domain A checker cannot read the sender domain because the value is empty, is a full URL, contains extra path text, or is not a real domain. 1. Use only the domain part, such as `example.com` or `mail.example.com`. 2. Remove `https://`, page paths, spaces, and email display names. 3. If you copied an email address, keep only the part after `@`. 4. Run the checker again with the cleaned domain. 5. Use the same cleaned domain when you configure the Mailrith delivery connection and your email delivery service's domain authentication. ### Sender Domain Basics A checker found the domain exists, but you still need to confirm that the domain Mailrith uses is the same domain authenticated in your email delivery service. 1. Open the Mailrith delivery connection that sends from this domain. 2. Confirm the From email uses the domain subscribers should recognize. 3. Open your email delivery service and confirm that same domain or sending subdomain is verified. 4. Check SPF, DKIM, DMARC, and alignment for that domain. 5. Send a real test email and confirm the message headers show authentication passing for your domain. > Mailrith can use the sender identity you choose, but the actual authentication is controlled by your email delivery service and DNS. If alignment is failing, fix that service's domain setup first. Related resources: - [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md): Learn how the visible From domain must match SPF or DKIM. - [SPF](https://mailrith.com/guides/spf.md): Understand the return-path domain and SPF records. - [DKIM](https://mailrith.com/guides/dkim.md): Understand signing domains, selectors, and DKIM records. - [Email Delivery Connections](https://mailrith.com/docs/email-delivery-connections.md): Connect the email delivery service that sends Mailrith campaigns. - [Google Email Sender Guidelines](https://support.google.com/a/answer/81126): Google's current sender authentication and delivery guidance. ## Related Guides - [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email has several sender-related addresses, and each one has a different job in delivery and replies. - [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain, while reverse DNS helps inboxes check whether a sending IP has a sensible hostname. - [Email Headers and Message Format](https://mailrith.com/guides/email-headers-and-message-format.md): Message headers, MIME structure, and basic formatting rules help inboxes parse and trust an email.