كيفية إرسال بريد إلكتروني في Laravel باستخدام Markdown Template وباسم النطاق الخاص بك

إرسال البريد الإلكتروني من أكثر الوظائف استخداماً في تطبيقات الويب، سواء لإرسال رسائل الترحيب، تأكيد الحساب، إعادة تعيين كلمة المرور، الفواتير، إشعارات الطلبات أو الرسائل الإدارية.

يوفر Laravel نظاماً متكاملاً لإرسال البريد الإلكتروني من خلال Mailables، كما يسمح باستخدام Markdown Mail Templates لإنشاء رسائل بريد إلكتروني مرتبة ومتجاوبة دون الحاجة إلى كتابة HTML كامل يدوياً.

في هذا الدليل سنتعرف خطوة بخطوة على:

  • إعداد Laravel لإرسال البريد الإلكتروني.
  • إنشاء Mailable Class.
  • استخدام Markdown Template.
  • تمرير البيانات إلى البريد.
  • إرسال البريد باستخدام SMTP.
  • إرسال البريد باسم نطاقك مثل support@example.com.
  • إعداد Gmail بالطريقة الحديثة.
  • استخدام Queues لإرسال البريد في الخلفية.
  • تحسين وصول البريد باستخدام SPF وDKIM وDMARC.

كيف يعمل إرسال البريد في Laravel؟

Laravel لا يقوم بتوصيل البريد الإلكتروني بنفسه إلى صندوق المستلم، بل يتصل بمزود بريد إلكتروني.

يمكن أن يكون المزود:

SMTP Server
Mailgun
Postmark
Resend
Amazon SES
Cloudflare Email
أو مزود بريد تابع لشركة الاستضافة

بشكل مبسط:

Laravel
   │
   ▼
Mailable
   │
   ▼
Mail Provider
   │
   ▼
Internet
   │
   ▼
Gmail / Outlook / Yahoo / Corporate Mail

ما هو Mailable في Laravel؟

كل نوع بريد يتم إرساله من التطبيق يُفضل أن يمثله Class مستقل يسمى Mailable.

مثلاً:

WelcomeEmail
OrderCreated
InvoiceEmail
PasswordChanged
ContactMessage

الـ Mailable مسؤول عن تحديد:

  • عنوان البريد Subject.
  • قالب الرسالة.
  • البيانات التي سيتم تمريرها إلى القالب.
  • المرفقات إن وجدت.
  • بعض إعدادات المرسل والرد.

ما هو Markdown Mailable؟

Laravel تسمح بإنشاء رسائل باستخدام Markdown بدلاً من تصميم Email HTML كاملاً من الصفر.

Markdown Mailables توفر Components جاهزة مثل:

mail::message
mail::button
mail::panel
mail::table

ثم يقوم Laravel بتحويل Markdown إلى HTML مناسب للبريد الإلكتروني، بالإضافة إلى إنشاء نسخة نصية Plain Text للرسالة.

إنشاء نموذج إرسال البريد

لنفترض أن لدينا نموذجاً يحتوي على:

email_to
email_title
email_body

مثلاً:

<form method="POST" action="{{ route('email.send') }}">

    @csrf

    <input
        type="email"
        name="email_to"
        placeholder="Email"
        required
    >

    <input
        type="text"
        name="email_title"
        placeholder="Subject"
        required
    >

    <textarea
        name="email_body"
        placeholder="Message"
        required
    ></textarea>

    <button type="submit">
        Send Email
    </button>

</form>

إنشاء Route

داخل:

routes/web.php

نضيف:

use App\Http\Controllers\EmailController;

Route::post(
    '/send-email',
    [EmailController::class, 'send']
)->name('email.send');

إنشاء Mailable مع Markdown Template

يمكن إنشاء Mailable والقالب معاً باستخدام:

php artisan make:mail SendEmail --markdown=emails.send-email

سيقوم Laravel بإنشاء ملفين.

الأول:

app/Mail/SendEmail.php

والثاني:

resources/views/emails/send-email.blade.php

شكل Mailable في Laravel الحديثة

في الإصدارات الحديثة من Laravel يتم تنظيم إعداد Mailable باستخدام دوال:

envelope()
content()
attachments()

بدلاً من وضع كل إعدادات البريد داخل دالة build() كما كان شائعاً في الإصدارات القديمة.

إنشاء SendEmail Mailable

<?php

namespace App\Mail;

use Illuminate\Bus\Queueable;
use Illuminate\Mail\Mailable;
use Illuminate\Mail\Mailables\Content;
use Illuminate\Mail\Mailables\Envelope;
use Illuminate\Queue\SerializesModels;

class SendEmail extends Mailable
{
    use Queueable, SerializesModels;

    public function __construct(
        public string $emailTitle,
        public string $emailBody,
    ) {
    }


    public function envelope(): Envelope
    {
        return new Envelope(
            subject: $this->emailTitle,
        );
    }


    public function content(): Content
    {
        return new Content(
            markdown: 'emails.send-email',
        );
    }


    public function attachments(): array
    {
        return [];
    }
}

ما هي envelope()؟

دالة:

envelope()

مسؤولة عن بيانات الرسالة مثل:

Subject
From
Reply-To

في المثال السابق:

return new Envelope(
    subject: $this->emailTitle,
);

قمنا بجعل عنوان البريد يأتي من المتغير:

$emailTitle

ما هي content()؟

دالة:

content()

تحدد القالب الذي سيتم استخدامه لإنشاء محتوى الرسالة.

بما أننا نستخدم Markdown:

return new Content(
    markdown: 'emails.send-email',
);

فإن Laravel سيبحث عن:

resources/views/emails/send-email.blade.php

تمرير البيانات إلى Markdown Template

عندما تكون Properties في الـ Mailable معرفة كـ Public:

public string $emailTitle
public string $emailBody

يمكن الوصول إليها مباشرة داخل Blade.

مثلاً:

# {{ $emailTitle }}

{{ $emailBody }}

إنشاء Markdown Template

افتح:

resources/views/emails/send-email.blade.php

واكتب:

<x-mail::message>

# {{ $emailTitle }}

{{ $emailBody }}

Thanks,<br>
{{ config('app.name') }}

</x-mail::message>

ملاحظة حول صيغة Markdown القديمة والجديدة

قد تجد في شروحات Laravel القديمة:

@component('mail::message')

# Hello

@endcomponent

أما في الإصدارات الحديثة فيتم عادة استخدام Blade Components:

<x-mail::message>

# Hello

</x-mail::message>

وهي الصيغة الأكثر وضوحاً في المشاريع الحديثة.

إرسال البريد من Controller

أنشئ Controller:

php artisan make:controller EmailController

ثم:

<?php

namespace App\Http\Controllers;

use App\Mail\SendEmail;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Mail;

class EmailController extends Controller
{
    public function send(Request $request)
    {
        $validated = $request->validate([

            'email_to' => [
                'required',
                'email',
            ],

            'email_title' => [
                'required',
                'string',
                'max:255',
            ],

            'email_body' => [
                'required',
                'string',
            ],

        ]);


        Mail::to($validated['email_to'])
            ->send(
                new SendEmail(
                    $validated['email_title'],
                    $validated['email_body']
                )
            );


        return back()->with(
            'success',
            'تم إرسال البريد الإلكتروني بنجاح'
        );
    }
}

لماذا Validation مهمة؟

لا ينبغي تمرير بيانات Request مباشرة إلى البريد دون التحقق منها.

مثلاً:

'email_to' => ['required', 'email']

يتأكد أن البريد المدخل بصيغة صحيحة.

كما أن:

'email_title' => [
    'required',
    'string',
    'max:255',
]

يمنع استقبال Subject غير متوقع أو كبير جداً.

إضافة زر داخل Markdown Email

Laravel توفر Component جاهزاً للأزرار:

<x-mail::button :url="$url">
عرض التفاصيل
</x-mail::button>

مثلاً:

<x-mail::message>

# تم إنشاء طلبك بنجاح

شكراً لاستخدام خدماتنا.

<x-mail::button :url="$url">
عرض الطلب
</x-mail::button>

Thanks,<br>
{{ config('app.name') }}

</x-mail::message>

تمرير URL إلى القالب

يمكن إضافته إلى Constructor:

public function __construct(
    public string $emailTitle,
    public string $emailBody,
    public string $url,
) {
}

ثم استخدام:

{{ $url }}

داخل Blade.

استخدام Panel داخل Markdown Email

<x-mail::panel>

هذه ملاحظة مهمة خاصة بالحساب.

</x-mail::panel>

وهي مناسبة لإظهار معلومة بارزة داخل البريد.

إنشاء جدول داخل البريد

<x-mail::table>

| المنتج | الكمية | السعر |
|:-------|:-------:|------:|
| Product A | 1 | $100 |
| Product B | 2 | $50 |

</x-mail::table>

وهو مفيد للفواتير والطلبات والتقارير.

إعداد خدمة البريد في Laravel

إعدادات البريد الأساسية توجد في:

config/mail.php

لكن القيم الحساسة مثل:

SMTP Username
SMTP Password
API Key

يتم تخزينها عادة داخل:

.env

مثال إعداد SMTP

الإعداد العام يكون قريباً من:

MAIL_MAILER=smtp

MAIL_HOST=smtp.example.com

MAIL_PORT=587

MAIL_USERNAME=mailer@example.com

MAIL_PASSWORD=your-secret-password

MAIL_ENCRYPTION=tls

MAIL_FROM_ADDRESS=mailer@example.com

MAIL_FROM_NAME="${APP_NAME}"

لكن القيم الدقيقة تعتمد على مزود البريد.

بعض مزودي البريد يستخدمون:

587 + STARTTLS

والبعض قد يوفر:

465 + TLS/SSL

لذلك يجب دائماً استخدام القيم التي يوفرها مزود البريد نفسه.

إرسال البريد باسم النطاق الخاص بك

إذا كان لديك نطاق:

example.com

يمكن إنشاء بريد مثل:

support@example.com

info@example.com

no-reply@example.com

ثم استخدام بيانات SMTP الخاصة بهذا البريد داخل Laravel.

مثال باستخدام بريد الاستضافة

لنفترض أن شركة الاستضافة أعطتك:

Email:
support@example.com

SMTP:
mail.example.com

Port:
465

يمكن أن تصبح إعدادات Laravel:

MAIL_MAILER=smtp

MAIL_HOST=mail.example.com

MAIL_PORT=465

MAIL_USERNAME=support@example.com

MAIL_PASSWORD=YOUR_MAIL_PASSWORD

MAIL_ENCRYPTION=ssl

MAIL_FROM_ADDRESS=support@example.com

MAIL_FROM_NAME="${APP_NAME}"

لكن لا تعتمد على هذا المثال كإعداد ثابت لكل شركات الاستضافة؛ استخدم دائماً SMTP Host وPort وطريقة التشفير التي تظهر في إعدادات حساب البريد لدى مزودك.

من أين أحصل على SMTP Settings؟

إذا كنت تستخدم cPanel مثلاً، غالباً يمكن الوصول إلى:

Email Accounts
    ↓
Connect Devices

أو

Set Up Mail Client

وستجد معلومات مثل:

Outgoing Server
SMTP Port
Username
Encryption

لا تضع كلمة المرور داخل Source Code

من الأخطاء الخطيرة كتابة:

MAIL_PASSWORD=real-password

داخل مثال منشور على موقع أو GitHub باستخدام كلمة المرور الحقيقية.

استخدم دائماً قيماً وهمية في المقالات:

MAIL_PASSWORD=your-mail-password

ولا تقم بعمل Commit لملف:

.env

إلى Repository عام.

إرسال البريد باستخدام Gmail SMTP

يمكن استخدام Gmail أثناء التطوير أو في بعض السيناريوهات البسيطة، لكن يجب الانتباه إلى أن الطريقة القديمة التي تعتمد على:

Less Secure Apps

لم تعد متاحة.

كما لا ينبغي وضع كلمة مرور حساب Google العادية داخل Laravel.

الطريقة الحديثة لاستخدام Gmail SMTP

عند استخدام Gmail مع SMTP، أحد الخيارات المتاحة لبعض حسابات Google هو:

  1. تفعيل Two-Step Verification.
  2. إنشاء App Password.
  3. استخدام App Password داخل Laravel بدلاً من كلمة مرور الحساب الأساسية.

مثال:

MAIL_MAILER=smtp

MAIL_HOST=smtp.gmail.com

MAIL_PORT=587

MAIL_USERNAME=youraccount@gmail.com

MAIL_PASSWORD=YOUR_APP_PASSWORD

MAIL_ENCRYPTION=tls

MAIL_FROM_ADDRESS=youraccount@gmail.com

MAIL_FROM_NAME="${APP_NAME}"

لماذا لا نستخدم كلمة مرور Gmail العادية؟

Google شددت سياسات المصادقة للتطبيقات الخارجية ولم تعد الطريقة القديمة التي تعتمد فقط على Username + Password وLess Secure Apps هي الطريقة المقبولة.

App Password عبارة عن Password مخصصة لتطبيق معين وتختلف عن كلمة مرور حساب Google الأساسية.

ويتوفر استخدامها عندما تكون إعدادات الحساب تسمح بذلك.

هل Gmail مناسب لإرسال بريد Production؟

يمكن استخدام Gmail لبعض التطبيقات الصغيرة، لكنه ليس دائماً الخيار المثالي لنظام Production يرسل كميات كبيرة من الرسائل.

في التطبيقات التجارية يفضل التفكير في خدمات Transactional Email مثل:

Amazon SES
Postmark
Mailgun
Resend

لأنها مصممة أساساً لإرسال البريد البرمجي، وتوفر عادة أدوات أفضل لمراقبة:

Delivery
Bounces
Complaints
Reputation
Logs

SMTP أم API؟

Laravel تدعم SMTP، لكنها تدعم أيضاً عدداً من Mail Drivers المبنية على APIs.

مثلاً:

Laravel
   │
   ├── SMTP
   │
   ├── Mailgun API
   │
   ├── Postmark API
   │
   ├── Resend API
   │
   └── Amazon SES

في التطبيقات الكبيرة، API-based Mail Drivers تكون خياراً جيداً لأنها مخصصة للتكامل البرمجي وغالباً توفر إمكانيات مراقبة وتسليم أفضل.

إرسال البريد باسم Domain لا يعني فقط تغيير MAIL_FROM_ADDRESS

من الأخطاء الشائعة الاعتقاد أن كتابة:

MAIL_FROM_ADDRESS=support@example.com

يكفي لإرسال بريد موثوق باسم النطاق.

الأمر لا يعمل بهذه البساطة.

يجب أن يكون مزود البريد مخولاً فعلياً للإرسال باسم:

example.com

وإلا قد يتم تصنيف الرسالة Spam أو رفضها.

ما هي SPF وDKIM وDMARC؟

لتحسين موثوقية البريد المرسل باسم نطاقك يجب إعداد DNS Records الخاصة بالبريد.

SPF

تحدد الخوادم المسموح لها بإرسال البريد باسم Domain الخاص بك.

DKIM

تضيف توقيعاً رقمياً للبريد يسمح لخادم المستلم بالتحقق من أن الرسالة مرسلة من مصدر مصرح به ولم يتم تعديلها أثناء النقل.

DMARC

تحدد السياسة التي يجب اتباعها عندما يفشل البريد في التحقق من SPF أو DKIM، كما تسمح بالحصول على تقارير عن استخدام Domain في البريد.

البنية الصحيحة لإرسال بريد باسم نطاقك

Laravel
   │
   ▼
Authorized Mail Provider
   │
   ▼
SPF / DKIM
   │
   ▼
Receiving Mail Server
   │
   ▼
Inbox

أما وجود:

MAIL_FROM_ADDRESS=anything@example.com

دون إعداد Domain لدى مزود البريد لا يجعل الرسالة موثوقة تلقائياً.

تغيير اسم المرسل

داخل:

.env

يمكن استخدام:

APP_NAME="My Company"

MAIL_FROM_NAME="${APP_NAME}"

ويظهر للمستخدم مثلاً:

From:
My Company <support@example.com>

تحديد From داخل Mailable

يمكن أيضاً تحديد المرسل داخل envelope().

use Illuminate\Mail\Mailables\Address;
use Illuminate\Mail\Mailables\Envelope;

public function envelope(): Envelope
{
    return new Envelope(

        from: new Address(
            'support@example.com',
            'My Company'
        ),

        subject: $this->emailTitle,

    );
}

لكن إذا كان جميع رسائل التطبيق تستخدم نفس المرسل فمن الأفضل عادة تحديده بشكل مركزي في إعدادات Mail.

إضافة Reply-To

يمكن أن ترسل الرسالة من:

no-reply@example.com

لكن تجعل رد المستخدم يذهب إلى:

support@example.com

مثلاً:

public function envelope(): Envelope
{
    return new Envelope(

        replyTo: [
            new Address(
                'support@example.com',
                'Support Team'
            ),
        ],

        subject: $this->emailTitle,

    );
}

إرسال CC وBCC

Laravel تسمح باستخدام:

Mail::to($user)
    ->cc($manager)
    ->bcc($archive)
    ->send(
        new SendEmail(
            $title,
            $body
        )
    );

حيث:

to  = المستلم الرئيسي
cc  = نسخة ظاهرة
bcc = نسخة مخفية

إرسال البريد باستخدام Queue

إرسال البريد عملية اتصال بخدمة خارجية، وبالتالي قد تستغرق وقتاً.

إذا استخدمنا:

Mail::to($user)->send(...);

سينتظر HTTP Request إلى أن تتم محاولة إرسال الرسالة.

في التطبيقات الحقيقية يفضل استخدام Queue:

Mail::to($user)
    ->queue(
        new SendEmail(
            $title,
            $body
        )
    );

لماذا Queue أفضل؟

بدلاً من:

User
  ↓
Submit Form
  ↓
Connect SMTP
  ↓
Send Email
  ↓
Wait
  ↓
Response

يمكن أن يصبح:

User
  ↓
Submit Form
  ↓
Add Email To Queue
  ↓
Response


Queue Worker
     ↓
Send Email

وبذلك يحصل المستخدم على استجابة أسرع.

تأخير إرسال البريد

يمكن أيضاً إرسال البريد لاحقاً:

Mail::to($user)
    ->later(
        now()->addMinutes(10),
        new SendEmail(
            $title,
            $body
        )
    );

وهذا مفيد في السيناريوهات التي تتطلب تأخيراً مقصوداً في الإرسال.

إرفاق ملف مع البريد

يمكن استخدام دالة:

attachments()

داخل Mailable.

مثلاً:

use Illuminate\Mail\Mailables\Attachment;

public function attachments(): array
{
    return [

        Attachment::fromPath(
            storage_path(
                'app/invoices/invoice.pdf'
            )
        ),

    ];
}

إرسال Invoice باسم مختلف

Attachment::fromPath(
    storage_path(
        'app/invoices/invoice.pdf'
    )
)->as('invoice.pdf')

معاينة البريد في المتصفح

أثناء التطوير يمكن إرجاع Mailable من Route لمعاينة تصميم الرسالة دون إرسالها فعلياً.

Route::get('/preview-email', function () {

    return new SendEmail(
        'عنوان تجريبي',
        'هذه رسالة تجريبية'
    );

});

وهذه طريقة مفيدة جداً لتعديل Markdown Template بسرعة.

إرسال البريد أثناء Local Development

أثناء التطوير لا يفضل دائماً إرسال رسائل حقيقية إلى المستخدمين.

يمكن استخدام خدمات Testing مثل Mailtrap أو Mailpit حسب بيئة التطوير.

كما يمكن استخدام Mailer:

MAIL_MAILER=log

في بعض السيناريوهات لتسجيل محتوى البريد بدلاً من إرساله فعلياً.

اختبار إرسال البريد في Laravel

في Automated Tests لا نريد عادة إرسال بريد حقيقي.

يمكن استخدام:

use Illuminate\Support\Facades\Mail;

Mail::fake();

ثم تنفيذ العملية:

$this->post('/send-email', [
    'email_to' => 'user@example.com',
    'email_title' => 'Hello',
    'email_body' => 'Test Email',
]);

ثم التأكد من أن Mailable تم إرساله:

Mail::assertSent(SendEmail::class);

عدم استخدام بيانات المستخدم مباشرة كـ From

إذا كان لديك Contact Form يحتوي:

Name
Email
Message

قد تفكر في جعل:

From = user@email.com

لكن هذا يمكن أن يسبب مشاكل في SPF وDMARC لأن خادمك غير مخول للإرسال باسم Domain الخاص بالمستخدم.

الأفضل أن ترسل الرسالة من بريد Domain الخاص بك:

From:
website@example.com

ثم تستخدم بريد المستخدم كـ:

Reply-To:
user@email.com

وبالتالي عند الضغط على Reply يصل الرد إلى المستخدم، بينما يبقى البريد المرسل متوافقاً مع Domain الخاص بك.

حماية Contact Form من Spam

إذا كان Endpoint إرسال البريد متاحاً للعامة، فيجب حمايته من إساءة الاستخدام.

من المهم استخدام بعض الإجراءات مثل:

  • Validation.
  • Rate Limiting.
  • CSRF Protection في Web Forms.
  • CAPTCHA عند الحاجة.
  • عدم السماح للمستخدم بتحديد From عشوائياً.

وإلا يمكن أن يتحول Endpoint إلى أداة لإرسال Spam.

إضافة Rate Limiting إلى Route

مثلاً:

Route::post(
    '/send-email',
    [EmailController::class, 'send']
)
->middleware('throttle:5,1')
->name('email.send');

وبهذا نحد من عدد الطلبات المسموح بها خلال مدة معينة.

أخطاء شائعة عند إرسال البريد من Laravel

استخدام Gmail Less Secure Apps

هذه طريقة قديمة ولم تعد مناسبة.

استخدم طريقة المصادقة التي يدعمها حساب Google حالياً، مثل App Password عندما تكون متاحة أو OAuth في السيناريوهات التي تتطلب ذلك.

استخدام كلمة المرور الحقيقية داخل المقال أو GitHub

استخدم Secret داخل .env ولا تنشر Credentials الحقيقية.

استخدام build() في شرح Laravel حديث دون توضيح

الكود القديم قد يستمر بالظهور في مشاريع وإصدارات سابقة، لكن الطريقة الحديثة تعتمد:

envelope()
content()
attachments()

عدم عمل Validation للبريد

تحقق دائماً من Recipient وSubject والمحتوى.

الإرسال المباشر داخل Request طويل

استخدم Queues عندما يكون البريد جزءاً من Production Workflow.

تغيير MAIL_FROM_ADDRESS فقط

هذا لا يكفي لإثبات ملكية Domain أو الحصول على Deliverability جيدة.

عدم إعداد SPF وDKIM

يمكن أن يؤدي ذلك إلى Spam أو رفض الرسائل من بعض مزودي البريد.

استخدام بريد العميل كـ From

استخدم Reply-To بدلاً من ذلك في Contact Forms.

تشغيل config cache بعد تغيير .env دون تحديثه

إذا كان التطبيق يستخدم Configuration Cache وبعد تعديل إعدادات البريد يمكنك تشغيل:

php artisan config:clear

ثم في Production حسب طريقة النشر:

php artisan config:cache

مثال نهائي كامل

.env

APP_NAME="My Website"

MAIL_MAILER=smtp

MAIL_HOST=mail.example.com

MAIL_PORT=587

MAIL_USERNAME=support@example.com

MAIL_PASSWORD=your-secret-password

MAIL_ENCRYPTION=tls

MAIL_FROM_ADDRESS=support@example.com

MAIL_FROM_NAME="${APP_NAME}"

Mailable

<?php

namespace App\Mail;

use Illuminate\Bus\Queueable;
use Illuminate\Mail\Mailable;
use Illuminate\Mail\Mailables\Content;
use Illuminate\Mail\Mailables\Envelope;
use Illuminate\Queue\SerializesModels;

class SendEmail extends Mailable
{
    use Queueable, SerializesModels;

    public function __construct(
        public string $emailTitle,
        public string $emailBody,
    ) {
    }


    public function envelope(): Envelope
    {
        return new Envelope(
            subject: $this->emailTitle,
        );
    }


    public function content(): Content
    {
        return new Content(
            markdown: 'emails.send-email',
        );
    }


    public function attachments(): array
    {
        return [];
    }
}

Markdown Template

<x-mail::message>

# {{ $emailTitle }}

{{ $emailBody }}

<x-mail::button :url="config('app.url')">
زيارة الموقع
</x-mail::button>

Thanks,<br>
{{ config('app.name') }}

</x-mail::message>

Controller

public function send(Request $request)
{
    $validated = $request->validate([

        'email_to' => [
            'required',
            'email',
        ],

        'email_title' => [
            'required',
            'string',
            'max:255',
        ],

        'email_body' => [
            'required',
            'string',
        ],

    ]);


    Mail::to($validated['email_to'])
        ->queue(
            new SendEmail(
                $validated['email_title'],
                $validated['email_body']
            )
        );


    return back()->with(
        'success',
        'تمت إضافة الرسالة إلى قائمة الإرسال'
    );
}

الخلاصة

إرسال البريد الإلكتروني في Laravel يتكون بشكل أساسي من ثلاثة أجزاء:

Mail Configuration
        +
Mailable Class
        +
Email Template

ويكون التدفق الكامل:

Laravel Controller
        │
        ▼
Mailable
        │
        ▼
Markdown Template
        │
        ▼
Mail Driver
        │
        ▼
SMTP / Email API
        │
        ▼
Recipient

وفي Laravel الحديثة يفضل تنظيم الـ Mailable باستخدام:

envelope()
content()
attachments()

واستخدام Markdown Mailables عندما نريد إنشاء رسائل جميلة ومنظمة بسرعة.

أما إذا أردنا إرسال البريد باسم Domain الخاص بنا مثل:

support@example.com

فلا يكفي تغيير From Address فقط، بل يجب استخدام مزود بريد مخول بإرسال البريد باسم Domain وإعداد سجلات DNS المناسبة مثل:

SPF
DKIM
DMARC

وفي التطبيقات الحقيقية يفضل أيضاً إرسال البريد باستخدام Laravel Queues لتجنب تأخير HTTP Requests، واستخدام مزود Transactional Email مناسب عندما يصبح حجم الرسائل كبيراً.

بهذه البنية يصبح نظام البريد أكثر أماناً وتنظيماً، وتزداد فرص وصول الرسائل إلى Inbox بدلاً من Spam، كما يصبح من السهل تطوير النظام لاحقاً لإضافة الفواتير والمرفقات والإشعارات ورسائل المستخدمين المختلفة.