The short answer

Treat incoming and outgoing email as two separate systems. If you can send but not receive, start with the address, mailbox, MX records, storage, forwarding, and inbound filters. If you can receive but not send, start with sign-in, the outgoing server or provider, account restrictions, sending limits, and authentication.

Do not change several DNS records at once. Run controlled tests, save the exact error, and fix the earliest layer that fails.

First, prove what is actually broken

Create four test messages using an outside Gmail or Microsoft account:

1. Outside account to business address.
2. Business address to outside account.
3. Reply from outside account to the business message.
4. Reply from business account to the outside message.

Use unique subjects with the date and direction, such as INBOUND TEST A and OUTBOUND TEST A. Record the time sent, sender, recipient, app used, and result.

Then try the business provider’s own webmail. If webmail works but the phone app does not, DNS and the mailbox are probably not your first problem. The app connection is.

If you can send but cannot receive

Work down this list in order:

1. Confirm the exact address exists

Check spelling, domain, mailbox status, aliases, and groups. If the address is an alias or shared address, confirm that it still routes to an active user and accepts mail from outside the organization.

2. Read the sender’s bounce

Ask the outside sender for the complete non-delivery report, not a screenshot that cuts off the code. The status often tells you where to look:

Do not treat this as a complete universal dictionary. Copy the full code and look it up in the receiving or sending provider’s current documentation. Microsoft’s Exchange Online NDR reference shows that different codes can identify invalid recipients, SPF failures, authentication requirements, routing problems, and other distinct causes.

3. Verify MX routing

MX records should point incoming mail to the active provider. Compare the public record with the value shown inside the provider’s administrator account. Old and new provider records mixed together can send mail to an account you no longer check.

Do not edit SPF because receiving is broken. SPF normally helps other systems evaluate mail sent from your domain. It does not tell senders where your inbox lives.

4. Check the mailbox itself

Look for:

• expired service or missing license.
• full storage.
• disabled or suspended account.
• quarantine or spam.
• inbox rules and forwarding.
• a catch-all sending the message elsewhere.
• group settings that reject outside senders.

Search all mail before deciding it never arrived.

If you can receive but cannot send

1. Send from provider webmail

If webmail sends successfully but Outlook, Apple Mail, or another app fails, focus on the app’s outgoing connection. Re-add the account using the provider’s supported sign-in before manually editing ports.

2. Save the full error

“Message not sent” is not enough. Record whether the failure happens immediately, remains in the Outbox, or returns later as a bounce. Copy the SMTP or provider code.

3. Check the outgoing identity

Verify the From address, SMTP username, permission to send as an alias, and Reply-To. A person may receive mail sent to hello@ but lack permission to send as hello@.

4. Check security and account status

Recent password changes, expired app passwords, blocked sign-ins, disabled SMTP authentication, unusual-activity holds, or a full account can prevent sending. Microsoft’s consumer Outlook guidance notes that full cloud storage can stop both sending and receiving, while business providers may expose the problem in an administrator panel.

5. Check sending behavior

Providers may restrict new accounts, unusual volume, large recipient lists, repeated failed addresses, or compromised accounts. Do not solve this by switching domains or breaking a list into deceptive batches. Stop the sending, identify the trigger, secure the account if necessary, and contact the provider.

Keep DNS authentication in the right place

SPF, DKIM, and DMARC matter when other systems evaluate messages sent using your domain. A missing or failed record may produce spam placement or rejection, but it is not the first explanation for every mail problem.

Use message headers to see what actually happened. If a bounce names SPF, DKIM, or DMARC, check:

• which service sent the message.
• whether that service is authorized in SPF.
• whether DKIM signing is enabled for the correct domain.
• whether DMARC alignment matches the visible From domain.
• whether more than one SPF record was published.

Google’s sender guidelines require all senders to Gmail to use SPF or DKIM and set more requirements for high-volume senders. Follow the stricter instructions of the receiving and sending services involved rather than making random DNS changes.

Separate mailbox trouble from website trouble

A contact form, store, scanner, scheduling app, and newsletter platform can each send through a different path. Your personal mailbox may work while the website form fails, or the form may display a success message without delivering a notification.

Test each sender separately and add it to a register:

Know when to stop troubleshooting alone

Contact the provider with a compact evidence packet:

• domain and affected address.
• whether the failure is inbound or outbound.
• start time and whether anything changed beforehand.
• full bounce or error text.
• message ID and original headers when available.
• results from provider webmail and one outside account.
• screenshots of the provider’s own verification screen, with private data hidden.

Do not post full headers publicly without removing addresses, IP information, and identifiers. If you suspect account compromise, reset access and secure the administrator and domain accounts before continuing ordinary tests.

Sources and further reading

• Microsoft: Non-delivery reports and SMTP errors in Exchange Online
• Microsoft: Troubleshoot sending and receiving in Outlook
• Google: Email sender guidelines

If you are making email dependable for customers

The Email Marketing System can help you document the sending systems, authentication, permission, and monitoring that support subscriber email.

A free next step

You don't have to build this alone

Bring your questions, share what you're working on, and meet other women building businesses from home. It is free to join.

Join Our Community Free

Related Questions

• When should a small business use aliases, shared inboxes, or separate mailboxes such as support@?
• How do I read and send my domain email from Gmail or Outlook?
• Why are ordinary messages from my business email going to spam?
• How do I move business email to a new provider without losing mail or breaking delivery?